begin quoting Tracy R Reed as of Wed, Apr 20, 2005 at 08:58:31AM +0700: > Stewart Stremler wrote: > > A layer that doesn't add much isn't worth the overhead. > > Are you telling me that you log into your box as root?
Log in as? Sometimes. Do work as? No. But I'm not the typical user, either. Although I think that doing work as root is silly at best, and stupid at worst. > > Do we want 'security in depth'? Why not TWO passwords when logging in? > > That makes it deeper! And autologout for some short time-period as > > well. That's more secure. And lock-out-the-account on three failed > > login attempts. That's more secure... > > Two layers of the exact same security (passwords) does not buy you > anything. If they can breach one they can probably breach the other. So difficulties that don't add sufficient security aren't worthwhile. That's the point. > > The security that comes from a root/non-root distinction on a single-user > > machine is arguably not worth the tradeoff. At least, not at this time. > > But what tradeoff? That they have to enter a root password to use > click-n-run? Being told "You can't do that!" and having to become root (briefly) to 'fix' things, or getting prompted for the root password as the software tries to be clever about it. The former decreases usability for the user, and the user will naturally seek to minimize the discomfort. So they'll set the root password to "grandma" as that's easy to type and remember -- and then write it down on a post-it and stick it to the monitor. > > So what's the second step? > > There are many more steps. Not running unnnecessary services is one you > have already mentioned. That's not a step enabled by the root/non-root distinction. > Writing secure apps wherever possible (no > gratuitous uses of live data, do not auto-execute things, etc) and so on. Neither is that. Apologies for the lack of clarity. In this case, 'step' was implying a sequence. (So the root/non-root distinction makes disabling unnecessary services _harder_, rather than easier.) Given a root/non-root distinction, you're setting things up so that the user _can't_ do some things. On a single-user system, telling the user he *can't* do some things doesn't add much security, but does add a lot to difficulty. On a multi-user system, a root/non-root distinction is the first step, the second is giving each user a unique ID, and the third is making sure they can't mess up anything for the other users... The recent(ish) innovation of popping up a dialog to ask for the root password when you do something that requires root access worries me. It is no different, to me, than running as root. How do I know that it's a legitimate program asking for the root password? > >>than Windows is indeed faint praise. But when you are being compared > >>with Windows it does have to be said. > > > > Why? > > Because people often ask "Why is it better than Windows?" that's why. Unprompted? I have a hard time believing that. I get asked "Why don't you use [MS]Windows?", but that's not the same thing. [snip] > > No trojans downloaded by a user-process can run. If I compromise your > > system, I can't drop in my own shell-cum-keylogger into $HOME and exec > > that when you log in. I can't download my own program to your machine > > to start consuming your CPU cycles, or to get you to be a DDOS zombie, > > etc. -- the most I can do (maybe) is to exploit a _running_ process, > > which is cleaned up at the next reboot. > > In Windows-land it seems that things often get executed without even > being downloaded and saved to disk. Or maybe they are downloaded into a > temporary area somewhere. Well, buffer overflows run from the stack. But persistent-across-reboots intrusions have to live on the disk somewhere. > > The one advantage of the splatter-files-all-over-the-system approach is > > that you can then apply these sorts of restrictions to the filesystems. > > > > But we're not keeping that in mind when we build our systems these days. > > If you want security, it seems like that would be one of the first places > > to start.... and if you had such an organization in place, you could then > > *easily* justify 'not-running-as-root'. > > These restrictions are a good idea. SE Linux is the place to implement > them. You can also then make exceptions for things like X. Cool! And with RBAC, you no longer need the splatter-approach to manage it sensibly. -Stewart "Still want some good sandboxes." Stremler
pgpTgS6IYkNzQ.pgp
Description: PGP signature
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
