[ale] Linux Distributions

[Jim Popovitch]

On Wed, 2005-05-18 at 09:24 -0400, Chris Ricker wrote: 
> (note: I'm ignoring the additional wrinkle of SELinux, although my laptops 
> and desktops actually use that)
> 
> Your assumption about how the Linux I use works is wrong. I can burn a CD 
> on this laptop without being logged in as root. No suid is involved. It's 
> enabled out of the box by PAM magic (pam_console). For distros which don't 
> use pam_console, the equivalent should be done by a dedicated group and 
> sgid, not suid
> 
> The difference (PAM or sgid versus suid) is important because it gets back 
> to why we're going through the slight trouble in the first place. If I 
> make cdrecord suid so that any non-root user can burn CD, I've 
> accomplished very little. Any bug in a suid cdrecord (and, no offense to 
> Joerg, but I'm sure it has them!) could accidentally or deliberately do 
> anything anywhere on the box -- repartition my hard drive, overwrite data, 
> etc. That's not what's done, however. I get write access to my CD when I 
> log in because my cd device (/dev/hdc) gets chown'ed to me by PAM. I run 
> cdrecord, and can write to it, but I can't, say, write to my hard drive 
> (/dev/hda) because the permissions on /dev/hda won't let me. If I weren't 
> using pam_console, I'd do the equivalent by making /dev/hdc (and only 
> /dev/hdc) writable by group burn, and making cdrecord sgid to burn, and 
> get the same protection.
> 
> That's the point. I have a highly productive (or at least will once I 
> start ignoring this thread! ;-) easy-to-use laptop. I don't log in as root 
> on it. I don't have to use sudo or suid on it to do every little thing. 
> And the whole time I'm using it, I know that by using the system the way 
> the system was designed to run -- with privilege separation by user and 
> group -- I am helping ensure that all the apps I run to be productive, but 
> which I don't fully trust, aren't doing anything stupid. Even if they try 
> to do something stupid (like a hypothetical bug in cdrecord which writes 
> to the wrong device file), they can't because the system won't let them. 
> Can they overwrite my data? Sure. But so can I, without the help of any 
> buggy app. Nothing but backups protects me there. Can they do any other 
> damage? No, because they don't have access. The privilege separation helps 
> protect me from the software developers' mistakes.

Good points.  To me though, the risk is greater to my data than
to /bin.  /bin can be rebuild in 10 mins, /home can't.  (On a single
user system, the only thing in /home is the user directory)  So, while I
agree with your premise that privilege separation, selinux, ACLs, etc
all add to integrity, I think they only do to a minor point in the grand
scheme of things.  Privilege separation, selinux, ACLs, etc., don't
protect /home/jimpop, the area that is important to me (and presumably
normal Desktop users)

> I'm explicitly trusting the hardware - kernel - init - libc - login
> - PAM - shell chain, and limiting my exposure by not fully trusting the 
> rest of what I run. You, however, don't do that. You implicitly fully 
> trust all your software. When the software you use is buggy, you're more 
> exposed to the potential results of those bugs. That's your choice. I 
> don't agree that it's justifiable, but then it's your desktop.

First, I don't run as root and have never stated that I have.  The point 
of my involvement in this tread was to question the reasons behind a 20
year "wives tale" and to get at the root of the reason(s).  To say that 
all systems everywhere should have a minimum of 2 accounts (one privileged
and one not) is too broad a brush for me to paint with.

I don't blindly trust the software I use.  There is not practical way to trust
everything in a Linux install.  I do trust the distributor, and I trust
their security updates (to some extent).  However, this issue is really not 
relevant to a non-root install (at least for me) as the critical part of
my laptop system is not /bin, it is /home.  Anything in /home/jimpop can be
destroyed by any application I run.   So, application trust is necessary 
unless I personally take the time to test and verify all the applications 
I use.

-Jim P.