Re: Local system security
On Wed, 2011-01-05 at 14:10 -0500, Matt McCutchen wrote: On Wed, 2011-01-05 at 11:12 -0500, Adam Jackson wrote: (And of course what we're doing here is protecting against a malicious attacker who already has enough privileges to run code on your system, which means you're pretty far into having already lost. Meh.) I've seen this viewpoint a number of places. IMO, it's a shame that the community seems to be giving up on local system security. In various situations, it would be quite convenient if I could give other people shell accounts on my machine without risking compromise of all of my data. The virtualization solutions are more work to set up. You're putting words in my mouth just a little. The existing discussion was about denial of service attacks. The case I was making is that adequate defense against DoS requires programming techniques more subtle than simple prohibition of abstract sockets, and (more broadly) a system that assures that resources are fairly allocated, for arbitrarily complex definitions of fair. If you have a malicious user who can run code on your machine, you've granted him CPU time. You have already lost. You're deciding how much to lose. The position you're painting me in is in opposition to: [...] risking compromise of all my data [...] and at no point was I arguing that access control or integrity were unimportant. If they weren't, we wouldn't bother with xauth at all. And they are concepts that are entirely achievable even within the unix model. You're still relying on the absence of bugs, but okay, that's always the gamble we make. But prevention of DoS on the part of local actors is just not a game you can win. If nothing else, remember that the way Linux implements malloc() assumes you have infinite memory, which means you overcommit resources, which means failure happens. You can write code that prevents many DoS conditions and that's almost always worthwhile, but at the end of the day it's a system with overcommit and therefore you either need trust in your participants or policy to rein them in. DoS simply is not a security issue. There are many other adjectives you can apply to it - availability, reliability, quality, usability; desirable qualities all - but security is not one of them. If what you say is right, the many schools that still use large shared shell servers are relying on their users not to be too evil, or alternatively the users shouldn't use the servers for anything important. That's been true since at least the RTM worm. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Local system security
On Wed, Jan 5, 2011 at 4:13 PM, Adam Jackson a...@redhat.com wrote: But prevention of DoS on the part of local actors is just not a game you can win. If nothing else, remember that the way Linux implements malloc() assumes you have infinite memory, which means you overcommit resources, which means failure happens. You can write code that [snip] # echo 2 /proc/sys/vm/overcommit_memory # echo 0 /proc/sys/vm/overcommit_ratio :) (and good luck with that!) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Local system security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/05/2011 04:38 PM, Gregory Maxwell wrote: On Wed, Jan 5, 2011 at 4:13 PM, Adam Jackson a...@redhat.com wrote: But prevention of DoS on the part of local actors is just not a game you can win. If nothing else, remember that the way Linux implements malloc() assumes you have infinite memory, which means you overcommit resources, which means failure happens. You can write code that [snip] # echo 2 /proc/sys/vm/overcommit_memory # echo 0 /proc/sys/vm/overcommit_ratio :) (and good luck with that!) BTW SELinux confined users and cgroups can help somewhat control those nasty students, but stopping a DOS will still be difficult. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0k5r8ACgkQrlYvE4MpobNkVgCgn1WVRz2Hh+SfFJpGRm9uAPNR gSoAniwmk0GOsK4igotX08b/MgnBqhqa =EFCr -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Local system security
On Wed, 2011-01-05 at 16:13 -0500, Adam Jackson wrote: On Wed, 2011-01-05 at 14:10 -0500, Matt McCutchen wrote: On Wed, 2011-01-05 at 11:12 -0500, Adam Jackson wrote: (And of course what we're doing here is protecting against a malicious attacker who already has enough privileges to run code on your system, which means you're pretty far into having already lost. Meh.) I've seen this viewpoint a number of places. IMO, it's a shame that the community seems to be giving up on local system security. In various situations, it would be quite convenient if I could give other people shell accounts on my machine without risking compromise of all of my data. The virtualization solutions are more work to set up. You're putting words in my mouth just a little. The existing discussion was about denial of service attacks. OK, I misunderstood. Reading your remark by itself, I thought it referred to confidentiality and integrity too. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Local system security
On Wed, 05 Jan 2011 16:13:25 -0500 Adam Jackson a...@redhat.com wrote: But prevention of DoS on the part of local actors is just not a game you can win. If nothing else, remember that the way Linux implements malloc() assumes you have infinite memory, which means you overcommit resources, which means failure happens. As long as we say things like the first one, Oracle will continue to pretend that Solaris is somehow more suitable to deploy Sunray... As for the second one, look here (we ship with overcommit set to heuristic, which is Webkit crashes in Rawhide): https://bugzilla.redhat.com/show_bug.cgi?id=648319#c63 -- Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
