Mailinglist Archive: yast-devel (132 mails)

< Previous Next >
Re: [yast-devel] YaST / PolicyKit integration
  • From: Justin Haygood <jhaygood@xxxxxxxxxxx>
  • Date: Wed, 10 Oct 2007 09:48:55 -0400
  • Message-id: <1192024135.7782.14.camel@xxxxxxxxxxxxxxxxxxx>

On Wed, 2007-10-10 at 15:32 +0200, Marcus Meissner wrote:
> On Wed, Oct 10, 2007 at 09:26:24AM -0400, Justin Haygood wrote:
> > 
> > On Wed, 2007-10-10 at 15:19 +0200, Marcus Meissner wrote:
> > > On Mon, Oct 08, 2007 at 04:11:31PM -0400, Justin Haygood wrote:
> > > > (For some background on PolicyKit,
> > > > is a good read).
> > > > 
> > > > Basically.. here's an idea for openSUSE 11+. Make YaST use PolicyKit to
> > > > determine if it does certain actions or not. This would grant the
> > > > following:
> > > > 
> > > > 1. YaST (at least Qt and GTK+) itself will run as the user. This would
> > > > allow for many benefits, i.e., GUI code isn't run privileged, etc..
> > > > 2. The system administrator could allow certain modules to be run
> > > > without a root password.
> > > > 3. The actual programs doing the actions would be forced to be separated
> > > > from the UI code (a good design anyway), with something like the system
> > > > message bus (D-Bus) as the middle man.
> > > 
> > > They should be very strictly seperated and only offer choices a
> > > user really should be able to do.
> > > 
> > > There is always the very inherent danger of giving the user root-equivalent
> > > access, like we did with the package management stack in 10.1/SLE10.
> > > 
> > > This should not be possible of course.
> > > 
> > > Ciao, Marcus
> > 
> > The biggest thing about PolicyKit is that the exact abilities of the
> > user is configurable by the system administrator on an action by action
> > basis. I'm actually starting work on a YaST module to edit PolicyKit
> > policies (a few of these already exist for HAL actually).
> > 
> > For instance, of admin wants to allow user X to administer the HTTP
> > server using YaST, but doesn't want to give user X the root password, he
> > can configure the action(s) for administrating the HTTP server to be
> > able to use user X's own password for authorizing user X to perform the
> > action.
> True.
> Additionaly...
> I think to abstract actions where a user can more or less directly gain
> root access using such services is a wasted effort.
> For those cases just give him full sudo rights and be done.
> Ciao, Marcus

True. But still, there are MANY cases where you don't want a user to
have full sudo access, since the administrator might want a user to
perform certain actions without granting full root access, since many
things (i.e, YaST) require full root access.

The other MAJOR thing (which makes sudo a bad alternative) is the
problem of running toolkit code as root. There's just a whole list of
problems waiting to happen there.

The basic idea is this:

1. The Qt and GTK YaST control centers will run as the user running
them. This is a much more sane case. You don't want a bug in the image
loading library to make it possible to rootkit the system via YaST, just
because its running with full root privileges.

2. The only things that will require authorization by PolicyKit would be
the actions themselves (I think for now, we can presume an action means
"apply changes". The authorization by default will be ask for root
password, but the sysadmin (NOT the packages) can change this to ask for
the user password for certain users, completely deny access for others,
etc... We can use a YaST module for this actually, which I'm
experimenting with writing.

3. The actions can eventually get AppArmor profiles which makes sure the
actions are ONLY doing what they should be doing.

4. The abstraction of the UI and actions provides more benefits,
including remote 1:1 management (I can be sitting on my laptop and
administer a server without using yast-ncurses over SSH), easier
web-based management, or as Benji would love, a less hacky YMP
handler :).

1. The system is secure by default. It's already fairly secure, but this
makes it REALLY hard to be unsecure, since the only "privileged" code is
the actual "apply" stage, and even then, AppArmor can further lock it
2. The sysadmin is happy.. he doesn't have to give sudo or root access
to a user who only should be doing certain things that requires
privileged access, and he knows in full confidence that the control
center is extremely secure.

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >