[ale] Linux Distributions

[Chris Ricker]

On Tue, 17 May 2005, Jim Popovitch wrote:

> I say easy to use.  Again, NOPASSWD on a server makes good sense, but on
> my laptop?  Come on.  Imaging having to sudo (and give a password) every
> time you wanted to:
>   
>          dial a modem
>          burn a cd
>          connect to a wireless hotspot
>          use bluetooth
>          print
>          modify /etc/hosts
>          delete old system logs
>          add a new user so a friend can log in
>          play a game like quake
>          etc
> 
> Some of those things don't presently require sudo, this is due to the
> use of setuid.  HOWEVER, if you believe the diatribe about running as
> root on desktop PCs, you need to also believe the diatribe of using
> setuid.  SOo, wholistically you can either have a productive easy to use
> PC or you can have a pain-in-the-a**-to-use PC that is "more" secure.
> YMMV.

(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.

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.

later,
chris