begin quoting Tracy R Reed as of Tue, Apr 19, 2005 at 04:38:24PM +0700: > Stewart Stremler wrote: [snip] > > And nobody has even pointed out that if I can compromise your user account > > on your single-user machine, I can also (eventually) gain root. > > Sure you can. But we want security in depth, right? Several layers since > no one layer is ever likely to be perfect.
A layer that doesn't add much isn't worth the overhead. 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... What, the user has thrown the machine away? Security is a tradeoff. 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. > > My personal opinion is that not-logging-in-as-root is just a _first_ > > step, useless without all the rest. I should NEVER /have/ to become root > > except in dire circumstances that also warrant booting into > > single-user mode. So long as you structure a system where there are > > times when you NEED to gain superuser access for routine tasks, you > > have a potential security problem. "We're better than MSWindows" is > > damn faint praise. > > Precisely! It is just a first step. We agree completely here. And better So what's the second step? What sort of things does the root/non-root distinction let us do that enhances security of the user's data? > than Windows is indeed faint praise. But when you are being compared > with Windows it does have to be said. Why? We should strive to be good, safe, secure, and usable, not "better than them". It's a worthy goal in and of itself. > > Heh. Tracy and I have a long running disagreement about what constitutes > > security on a Linux box. :) > > Hmm... I'm not so sure about that. I bet we agree on the most important > aspects of what constitutes security on a Linux box. :) > > "Do you mount /home noexec? Is /usr ro? Why not?" > > /home as noexec? Wouldn't that prevent you from installing any > executables at all into your own ~/bin dir? Yup. > Not sure what that would > really buy me. 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. It apparently breaks X, however.... :( > Making /usr ro is a good idea I had never really > considered before though. I never write anything into /usr and always > put stuff into /usr/local. Although on occasion a system patch/update > from yum might try to change something in /usr but that is rare enough > that I can remount rw for that. Yup. Least privilege, remember? Why does anything need to write to /etc, /sbin, /usr, /usr/local, or /lib? Why does anything need to run from /var or /home? Why would anything outside of /sbin or /usr/sbin need setuid/setgid? 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'. -Stewart "J-random-user doesn't need a developer configuration" Stremler
pgpL1xrvcj0tr.pgp
Description: PGP signature
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
