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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
