Least privileges [was: Re: Fedora power management]

[Sjoerd Simons]

On Fri, Nov 19, 2004 at 11:35:00AM -0500, David Zeuthen wrote:
> On Fri, 2004-11-19 at 10:18 +0100, Martin Pitt wrote:
> > Why? Instead of neglecting the problem and having _everything_ run as
> > root, every callout and and other client can individually gain as much
> > privileges as it really needs. You exchange a daemon with lots of
> > communication (input validation!) that permanently runs as root with
> > some minimally privileged clients which run only a short time and have
> > relatively little input to check. How can this be a bad thing?
> >
> > E. g. pmount does most of its job as normal user and only switches to
> > root for function calls that really need them. A printer configuration
> > backend could be setgid lpadmin instead of setuid root (works very
> > well with CUPS, e. g. Ubuntu's CUPS does not run as root as well). A
> > network configuration callout needs to be suid root and immediately
> > drop everything but CAP_NET_ADMIN.
> > 
> > Please don't encourage laziness on the side of the authors of
> > callouts. People should be aware of the privileges of their scripts
> > and their possible security implications.
> > 
> 
> Hey, the callouts can drop privileges instead of being a setuid binary
> if you are concerned about that. 
> 
> Making them setuid root is a bad idea - remember, every joe random user
> who got an account on some home system can exec a suid binary; one that
> you only want haldaemon to execute, e.g. as a callout.

You can make these executable to just the hald user or group. But ofcourse any
setuid program (or program designed to run as root user for that matter) must do
very carefull checking
  
> Btw, can any joe random user that logs into a Ubuntu system use pmount
> to gain access to filesystems from, say, a USB2 hard drive? He shouldn't
> really, in my view. I understand that it may be a desirable thing
> though, we just don't allow that in Fedora because of security concerns.

Every user that is in group plugdev can do that. There is really no concept
of a ``local'' user in debian and ubuntu. Basically if your allowed to mount
disks, your always allowed to do that. It doesn't matter if your logged in
locally or from a remote location.

> My point is really that all such policy and privilege checking can be
> done in a single location instead of in each setuid binary; namely hal
> or D-BUS. Sure, we need to make an option called --use-pam-console for
> hald to respect to determine if this or that method is allowed to be
> invoked by the user [1].
> 
> [1] : Btw, it would be really nice with a standard distro independent
> way of determining if a user should be e.g. allowed to mount a file
> system; rename a disk label, shut down the computer etc. Is PAM being
> used in e.g. Debian or Ubuntu. What does SUSE do?

Debian and Ubuntu use pam, but not pam-console. To determine what user is
allowed to do what is indeed a general problem. 

For mounting removable volumes a debian/ubuntu user needs to be in the plugdev
group. (Or at least will be the case as soon as the new debian packages hit
unstab/testing)

> 
  [snip]
> 
> 
> See my mail to Sjoerd.

It could have gotten lost somewhere (at least i haven't seen it on the list
yet). I'll bounce them in a few seconds..

  Sjoerd
-- 
There is no likelihood man can ever tap the power of the atom.
		-- Robert Millikan, Nobel Prize in Physics, 1923
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal