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, http://people.freedesktop.org/~david/polkit-spec.html 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 :). Basically: 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 down. 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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org