[yast-devel] YaST / PolicyKit integration
(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. AppArmor can even be utilized by making the privileged helper programs that do the actual work only able to do what they are intended to be done. The split between the privileged helpers and the unprivileged UI can probably be made easier by some easy APIs integrated into YCP, etc.. I plan on learning on how to make YaST modules by writing a "System Policy Editor" which will manage PolicyKit policies. It seems to be a self-documenting XML format, that the policy editor can then parse and use to provide a nice easy to use policy editor. What do people think about this -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 08/10/2007, Justin Haygood <jhaygood@reaktix.com> wrote:
(For some background on PolicyKit, http://people.freedesktop.org/~david/polkit-spec.html is a good read).
Yes it has great potential.
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..
A very good thing. Had to use a massive hack for the YMP handler to communicate between privileged & unprivileged YaST.
2. The system administrator could allow certain modules to be run without a root password.
Again good, as long as you can restrict granted privileges to actions rather than applications, which I believe policykit will allow. There's also apparmor possibility as you mention later.
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.
Another very good thing. Although it would be a good idea to consider the use case of managing a system remotely. It should be possible to manage a remote suse machine using a YaST frontend locally for example, this could enable making changes on multiple machines at once etc. Klaus was working on ws-management interface to YaST (see http://idea.opensuse.org/content/ideas/yast-as-a-webservice) which it might be worth looking at. I believe it is functional to some extent, and might be exposable over dbus as well as http as it's soap.
What do people think about this
Sounds great. _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Mon, 2007-10-08 at 22:14 +0100, Benji Weber wrote:
On 08/10/2007, Justin Haygood <jhaygood@reaktix.com> wrote:
(For some background on PolicyKit, http://people.freedesktop.org/~david/polkit-spec.html is a good read).
Yes it has great potential.
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..
A very good thing. Had to use a massive hack for the YMP handler to communicate between privileged & unprivileged YaST.
Yes. Once PackageKit is completed and integrated, that might even be better for YMP :)
2. The system administrator could allow certain modules to be run without a root password.
Again good, as long as you can restrict granted privileges to actions rather than applications, which I believe policykit will allow. There's also apparmor possibility as you mention later.
Yes, PolicyKit is totally based around actions
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.
Another very good thing. Although it would be a good idea to consider the use case of managing a system remotely. It should be possible to manage a remote suse machine using a YaST frontend locally for example, this could enable making changes on multiple machines at once etc.
The separated modules can be exposed over pretty much anything, which makes the design just that much better, since the YaST actions are reusable from any context.
What do people think about this
Sounds great.
YaST is already the best system management tool in the world in my opinion, but it can still get even better :). -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Benji Weber <b.weber@warwick.ac.uk> [Oct 08. 2007 23:17]:
2. The system administrator could allow certain modules to be run without a root password.
Again good, as long as you can restrict granted privileges to actions rather than applications, which I believe policykit will allow. There's also apparmor possibility as you mention later.
AppArmor focuses on file access protection based on the uid of the calling process. So its doesn't really support 'role based' access control.
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.
Another very good thing. Although it would be a good idea to consider the use case of managing a system remotely. It should be possible to manage a remote suse machine using a YaST frontend locally for example, this could enable making changes on multiple machines at once etc.
Agreed. However we will probably restrict our own efforts to 1:1 remote management and leave 1:many management to other parts of the company (namely the SRM business unit). One of the development goals is certainly to break the backend ('Model'; scr, libstorage, libzypp, etc.), control layer ('Controller', ycp/perl code) and user interface ('View') into separate, loosely coupled entities and foster a 3-tier (Model-View-Controller) architecture.
Klaus was working on ws-management interface to YaST (see http://idea.opensuse.org/content/ideas/yast-as-a-webservice) which it might be worth looking at. I believe it is functional to some extent, and might be exposable over dbus as well as http as it's soap.
SOAP as a local communication protocol (e.g. over dbus) is too heavyweight. The nice thing about Ws-Management is its standardization and ease of integration into existing (ws-man based) management environments. Enabling remote management targets enterprise requirements and we should follow existing standards there. In detail this means - CIM (resp. WS-CIM == CIM over WS-Man) for the Model - Controller communication (low level functionality) - WS-Man (e.g. YaST as a webservice) for the Controller - Presentation Layer communication (high level functionality) - HTTP / HTML for the Presentation Layer - User Interface communication (dialogs) This will comply to existing standards, fit enterprise requirements and would also deliver on the interoperability promise. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Monday 08 October 2007 22:11:31 Justin Haygood wrote:
(For some background on PolicyKit, http://people.freedesktop.org/~david/polkit-spec.html is a good read).
Indeed a good read. I need to learn more about the design of actions and their restrictions. Sadly, the documentation is really bad (except for that link you posted)
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:
I followed the tutorial and seems nice. I have some questions anyway. From what I understood we would need: - Find most "actions" in YaST (we could start with something as smple as "apply" changes in some modules, and declare them to policykit - Create some YaST level wrapper of libpolkit so YCP modules could talk to PolicyKit just before doing some action. The problem is, the second part requires the action to be in a separate process, and this is not that "easy" to extract from YaST. When we start using someday things like CIM providers, then it is really easy, each method is a kind of action. and some process embedding the CIM server is enough.
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.
Yes, the benefits are clear.
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.
We already have separation of Modules (APIs) and clients (workflows). What can else you can separate? - UI descriptions. Which only work if your widgets are not dynamic. Otherwise you can extract the base, and attach the behavior in the controller, plus any widget change. - The controller. At least the 2 parts above are already separated from modules in YaST, so we could say, modules and their APIs are the "mechanisms", but the modules API is not that straightforward to extract as actions.
AppArmor can even be utilized by making the privileged helper programs that do the actual work only able to do what they are intended to be done. The split between the privileged helpers and the unprivileged UI can probably be made easier by some easy APIs integrated into YCP, etc..
Yes
I plan on learning on how to make YaST modules by writing a "System Policy Editor" which will manage PolicyKit policies. It seems to be a self-documenting XML format, that the policy editor can then parse and use to provide a nice easy to use policy editor.
Nice idea. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
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 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
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. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
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 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
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
participants (5)
-
Benji Weber -
Duncan Mac-Vicar Prett -
Justin Haygood -
Klaus Kaempf -
Marcus Meissner