Least privileges [was: Re: Fedora power management]

[David Zeuthen]

On Fri, 2004-11-19 at 18:37 +0100, Sjoerd Simons wrote:
> On Fri, Nov 19, 2004 at 11:35:00AM -0500, David Zeuthen wrote:
> > 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

Indeed.

<snip>

> > 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)
> 

Which would be nice to solve in a distribution/OS-independent way (I'm
not holding my breath though); I guess that for the changes planned here

 http://freedesktop.org/pipermail/hal/2004-November/001305.html

we'll just have to do a #ifdef PAM_CONSOLE, #ifdef PLUGDEV_GROUP inside
hald and so on. 

<brainstorming mood="hmm, doesn't stuff like this already exist or am I
just talking crap?">

However, that will not scale - e.g. on Fedora I'm not happy to only
switch on whether it's the console user or not. I'm sure you won't be
happy to let remote users invoke the Standby() or Shutdown() method call
in Debian either just because they are in the plugdev group :-). 

Really, it should be more fine grained, but hey, then someone with the
motivation might solve the problem at a later point in time. Btw, D-BUS
does include the '<policy at_console="true">' directive in the service
configuration - I think that is a bug as it is a pam-console-ism. 

Really, right now the service should check this, not D-BUS.

(though that might change at a later point in time and, in fact, it
might be ideal to do it in D-BUS[1] as it is centralized).

[1] : I envision that one would like to authorize method calls from a
process based on a number of things including UID, PID, (optionally)
SELinux domain, (optionally) whether user is logged in at console.

Ideally, the backends taking this input and saying grant/deny for a
method call should be pluggable, e.g. if I'm a big enterprise I store
shit like this using LDAP. Ideally there should be a way to determine
ahead of time whether one is allowed to invoke a method call so as to
prepare the UI (e.g. don't show the Power Off button if user is not
authorized to do so).

</brainstorming>

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

I was referring to the mail I linked to above.

Cheers,
David


_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal