Local system security

[Adam Jackson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110105/6c23038c/attachment.bin