Least privileges [was: Re: Fedora power management]

[Sjoerd Simons]

On Sat, Nov 20, 2004 at 05:56:48PM -0500, David Zeuthen wrote:
> 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:
> > > 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. 

The plugdev group only gives rights over pluggable devices (In debian just
being allowed to mount them)..  
> 
> <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 :-). 

See previous comment :)..
> 
> 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>

We do indeed need a solution for this. In debian i'm a little afraid for
getting too many groups. One for pmount (plugdev), one for networkmanager,
one for shutting down a machine etc.. That does indeed not scale very well.

  Sjoerd
-- 
So little time, so little to do.
		-- Oscar Levant
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal