Hey,
I've just added a new subpackage in the polkit SRPM called polkit-desktop-policy. This package will add two new system groups (the trailing _r signifies these are really roles, not ordinary groups)
- desktop_admin_r - desktop_user_r
The patch is here
http://cvs.fedoraproject.org/viewvc/devel/polkit/polkit.spec?r1=1.8&r2=1...
It works like this
1. If the desktop_admin_r group is non-empty, then users in the group are used for administrator authentication - see the polkit(8) man page for details:
http://hal.freedesktop.org/docs/polkit/polkit.8.html
If the desktop_admin_r group is empty, we just ask for the root password instead.
For example, the following is a screenshot where the users davidz and bateman are in the desktop_admin_r group:
http://people.freedesktop.org/~david/pkexec-with-desktop-admin-r.png
2. Second, if you are member of the desktop_admin_r group, then you should be allowed to do a lot of things without being interrupted by authentication dialogs. This part isn't complete, for now, it includes
org.gnome.clockapplet.mechanism.* - set timezone and system time org.freedesktop.devicekit.disks.* - all storage related things org.freedesktop.RealtimeKit1.* - run real-time processes
but we probably want to allow installing trusted packages, install trusted updates and remove packages. Without asking for a password. Probably more - Richard?
3. Third, if you are a member of the desktop_user_r group then you should be allowed to do a number of things - not as much as the desktop_admin_r role, but things like setting the time zone. For now, we only include
org.gnome.clockapplet.mechanism.settimezone
A couple of notes
- As we add/remove mechanisms (e.g. privileged apps using polkit), we need to update this package. That's fine.
- For this to be really useful, we need the User Account Editor that Matthias wrote about here
https://www.redhat.com/archives/fedora-desktop-list/2008-May/msg00006.html
Sadly no work has been done on this yet. Anyway, the main point is that we can add something like this
Account Type
(*) Standard User ( ) Administrative User
to this tool. We can also add more roles, e.g. "Restricted User" and also tailor policy for the mythical guest account.
- This is opt-in. If you don't want to use this, just don't add any users to the desktop_admin_r or desktop_user_r groups. Heck, just uninstall the package. Second, other third-party packages can easily override this thanks to how the polkit local authority works (see the pklocalauthority(8) man page for details).
- This should put an end to the (IMO misguided) request "please add first user to the 'wheel' group". The new 'wheel' is 'desktop_admin_r' and the new sudo(1) is pkexec(1). (Of course sudo(1) will still continue to work but it is not what we officially want to support. PolicyKit is, however)
- With support in the OS installer for automatically adding the first user to desktop_admin_r, we should be close to actually doing installs without the concept of a root password...
Of course this is not 100% useful until a) the OS installer knows about this; and b) we have an User Account Editor. But it is 90% there.
Finally, Matthias, can someone please add polkit-desktop-policy to the default desktop install? Thanks.
David
On Thu, 13.08.09 14:28, David Zeuthen (davidz@redhat.com) wrote:
Second, if you are member of the desktop_admin_r group, then you should be allowed to do a lot of things without being interrupted by authentication dialogs. This part isn't complete, for now, it includes
org.gnome.clockapplet.mechanism.* - set timezone and system time org.freedesktop.devicekit.disks.* - all storage related things org.freedesktop.RealtimeKit1.* - run real-time processes
rtkit should be accessible for normal desktop users already. Please move this to desktop_user_r!
I am assuming that this makes only sense if the upstream policy files in the various packages are more strict by default than what is shopped in polkit-desktop-policy. Right?
So, for a package that has used console-based auth by default before (like rtkit), how should their upstream policy files be changed? How does console-based auth and this new role-based out fit together?
Lennart
On Thu, 2009-08-13 at 20:55 +0200, Lennart Poettering wrote:
On Thu, 13.08.09 14:28, David Zeuthen (davidz@redhat.com) wrote:
Second, if you are member of the desktop_admin_r group, then you should be allowed to do a lot of things without being interrupted by authentication dialogs. This part isn't complete, for now, it includes
org.gnome.clockapplet.mechanism.* - set timezone and system time org.freedesktop.devicekit.disks.* - all storage related things org.freedesktop.RealtimeKit1.* - run real-time processes
rtkit should be accessible for normal desktop users already. Please move this to desktop_user_r!
I am assuming that this makes only sense if the upstream policy files in the various packages are more strict by default than what is shopped in polkit-desktop-policy. Right?
Right.
So, for a package that has used console-based auth by default before (like rtkit), how should their upstream policy files be changed? How does console-based auth and this new role-based out fit together?
I think it really depends. We've always wanted the defaults specified in the .policy files to, at least, be secure whilst also being usable. Now, with this role mechanism being available, we can be a bit more strict.
For example, IIRC someones pet peeve was that we only required user authentication, not admin authentication, for changing the system time. He was concerned about some vague attack vector and log files and what not. So to avoid endless discussions like that we're now changing this to require admin authentication.
Either way, allowing any user at the console to use rtkit seems fine to me so I would suggest not changing anything in rtkit. If people complain we can always just change things later (e.g. 1. a new rtkit release with other defaults in the .policy file; and 2. adding stuff for rtkit to polkit-desktop-policy).
FWIW, this whole area is subject to much discussion - it's the classic example trading off security for usability - and vice versa. But I, for one, definitely want to move Fedora in a direction where there are fewer authentication dialogs.
Hope this clarifies.
David
Hi,
This sounds pretty cool. I'm interested in some details:
On Thu, Aug 13, 2009 at 2:28 PM, David Zeuthendavidz@redhat.com wrote:
Hey,
I've just added a new subpackage in the polkit SRPM called polkit-desktop-policy. This package will add two new system groups (the trailing _r signifies these are really roles, not ordinary groups)
- desktop_admin_r - desktop_user_r
Are these defined by upstream PolicyKit? In other words, are these group names expected to be the same across OS vendors? Or just the concept of the two groups, and their names can vary?
1. If the desktop_admin_r group is non-empty, then users in the group are used for administrator authentication - see the polkit(8) man page for details:
http://hal.freedesktop.org/docs/polkit/polkit.8.html
If the desktop_admin_r group is empty, we just ask for the root password instead.
For example, the following is a screenshot where the users davidz and bateman are in the desktop_admin_r group:
http://people.freedesktop.org/~david/pkexec-with-desktop-admin-r.png
2. Second, if you are member of the desktop_admin_r group, then you should be allowed to do a lot of things without being interrupted by authentication dialogs. This part isn't complete, for now, it includes
org.gnome.clockapplet.mechanism.* - set timezone and system time org.freedesktop.devicekit.disks.* - all storage related things org.freedesktop.RealtimeKit1.* - run real-time processes
but we probably want to allow installing trusted packages, install trusted updates and remove packages. Without asking for a password. Probably more - Richard?
Hmmm. I very, VERY strongly think that installing OS updates should require no password by default in the unmanged case, and *especially* not a different "root" password. System time is probably in that area as well. If "make sound work without pops" requires the real-time process permission, then we definitely need that too.
So it sounds like your desktop_admin_r is equivalent to the unmanaged case? And desktop_user_r is roughly...what? Computer lab? But admins there aren't going to want people to be able to change the time.
- This should put an end to the (IMO misguided) request "please add first user to the 'wheel' group". The new 'wheel' is 'desktop_admin_r' and the new sudo(1) is pkexec(1).
See, this is what I don't like, is that "admin" here really means "execute arbitrary code as root" which I suggest we don't want to conflate with "install OS updates" and "make sound work without popping".
- With support in the OS installer for automatically adding the first user to desktop_admin_r, we should be close to actually doing installs without the concept of a root password...
The most important thing is to remove the root password from the default UI flows, But for example, the first time you typed "pkexec vi /etc/resolv.conf" (i.e. do something arbitrary as uid 0) when you're debugging some network problem, it'd be cool if that prompted you for a root password. In fact, if one wasn't set yet, offered to let you set it. Then we could axe the root password from the livecd installer prompt, and it becomes on-demand.
On Thu, 2009-08-13 at 15:41 -0400, Colin Walters wrote:
Are these defined by upstream PolicyKit? In other words, are these group names expected to be the same across OS vendors? Or just the concept of the two groups, and their names can vary?
Not yet. We might want a polkit-policy tarballs that define these roles (and possibly others) and the associated policy. I fwd'ed the original mail to polkit-devel-list for other distros to consider this.
but we probably want to allow installing trusted packages, install trusted updates and remove packages. Without asking for a password. Probably more - Richard?
Hmmm. I very, VERY strongly think that installing OS updates should require no password by default in the unmanged case, and *especially* not a different "root" password. System time is probably in that area as well. If "make sound work without pops" requires the real-time process permission, then we definitely need that too.
Right, so granting the authorization to install OS updates w/o a password for desktop_user_r and desktop_admin_r is what we want.
So it sounds like your desktop_admin_r is equivalent to the unmanaged case? And desktop_user_r is roughly...what? Computer lab? But admins there aren't going to want people to be able to change the time.
The idea is that desktop_admin_r is for the owner(s) of the system - for example, the owner of a single-user laptop. The idea is that desktop_user_r is a non-owner or otherwise less privileged/trusted - for example, your kids on the shared computer system at home.
That's the _idea_ anyway. We might want to change this if we want to.
- This should put an end to the (IMO misguided) request "please add
first user to the 'wheel' group". The new 'wheel' is 'desktop_admin_r' and the new sudo(1) is pkexec(1).
See, this is what I don't like, is that "admin" here really means "execute arbitrary code as root" which I suggest we don't want to conflate with "install OS updates" and "make sound work without popping".
Right, so we just give this authorization only to desktop_admin_r. E.g. allow standard users to install trusted OS updates. Ditto for the rtkit stuff.
(And, btw, you _do need_ to enter the password for an admin user for 'pkexec bash' to work. Even if you are in desktop_admin_r. Ditto for installing untrusted/unsigned packages. And this is fine I think.)
- With support in the OS installer for automatically adding the first
user to desktop_admin_r, we should be close to actually doing installs without the concept of a root password...
The most important thing is to remove the root password from the default UI flows, But for example, the first time you typed "pkexec vi /etc/resolv.conf" (i.e. do something arbitrary as uid 0) when you're debugging some network problem, it'd be cool if that prompted you for a root password. In fact, if one wasn't set yet, offered to let you set it. Then we could axe the root password from the livecd installer prompt, and it becomes on-demand.
I think we want to completely disable the root account just like in OS X and Ubuntu. In my view, it just doesn't make sense to have a root password at all - shared secrets are really bad. One less password to worry about is really what you want.
David
On Thu, Aug 13, 2009 at 4:20 PM, David Zeuthendavidz@redhat.com wrote:
The idea is that desktop_admin_r is for the owner(s) of the system - for example, the owner of a single-user laptop. The idea is that desktop_user_r is a non-owner or otherwise less privileged/trusted - for example, your kids on the shared computer system at home.
So my kids can't change the system time? I dunno. I think what we need here is a wiki page which takes the current set of PolicyKit actions (in the default desktop image only, i.e. not including say virt-manager), and puts those actions into one of your two suggested roles.
If we're talking about kids, I'd probably be more concerned about usage-time limits or browser filtering, but neither of those fall under PolicyKit.
(And, btw, you _do need_ to enter the password for an admin user for 'pkexec bash' to work. Even if you are in desktop_admin_r. Ditto for installing untrusted/unsigned packages. And this is fine I think.)
Right, OK. No strong opinion here on what those things should require; we could make installing unsigned packages require you to do a little dance in front of the webcam for all I care =)
I think we want to completely disable the root account just like in OS X and Ubuntu. In my view, it just doesn't make sense to have a root password at all - shared secrets are really bad. One less password to worry about is really what you want.
I don't disagree that a root password is dumb for the unmanaged case. But we do want to have a good story for people deploying computer labs, and at least this is where Ubuntu's original "use sudo for everything" kind of fails. Also important here is the scenario where a technical person maintains a friend's or family member's computer. It should be easy for them to enable the root account and use it to recover/administer the machine.
On Thu, 2009-08-13 at 17:24 -0400, Colin Walters wrote:
On Thu, Aug 13, 2009 at 4:20 PM, David Zeuthendavidz@redhat.com wrote:
The idea is that desktop_admin_r is for the owner(s) of the system - for example, the owner of a single-user laptop. The idea is that desktop_user_r is a non-owner or otherwise less privileged/trusted - for example, your kids on the shared computer system at home.
So my kids can't change the system time? I dunno.
System time is sorta security sensitive so I'd rather they didn't.
And Ideally we'd just use NTP - our NTP story is weak at best, unfortunately.
I think what we need here is a wiki page which takes the current set of PolicyKit actions (in the default desktop image only, i.e. not including say virt-manager), and puts those actions into one of your two suggested roles.
Dunno if we need a wiki page - maybe we can just keep it in the spec file for now - otherwise it gets out of sync.
Anyway, the point here is that it is _hard_ to figure out _how_ these two roles should work - or what roles we actually need. I guess we need to experiment a bit with this. I don't pretend to know.
If we're talking about kids, I'd probably be more concerned about usage-time limits or browser filtering, but neither of those fall under PolicyKit.
Not directly, no.
(And, btw, you _do need_ to enter the password for an admin user for 'pkexec bash' to work. Even if you are in desktop_admin_r. Ditto for installing untrusted/unsigned packages. And this is fine I think.)
Right, OK. No strong opinion here on what those things should require; we could make installing unsigned packages require you to do a little dance in front of the webcam for all I care =)
Again, this is security vs usability. The thinking here is that operations that effectively give you a root shell requires trusted path. E.g. 'pkexec bash', installing unsigned packages etc. fall into this category.
So here you need to prove that you are the administrator - typically by entering a password but.. I guess.. pam_rps or some PAM module with a webcam and dance analyzing software works too. We also need this
http://www.youtube.com/watch?v=RfiQYRn7fBg ;-)
I think we want to completely disable the root account just like in OS X and Ubuntu. In my view, it just doesn't make sense to have a root password at all - shared secrets are really bad. One less password to worry about is really what you want.
I don't disagree that a root password is dumb for the unmanaged case. But we do want to have a good story for people deploying computer labs, and at least this is where Ubuntu's original "use sudo for everything" kind of fails. Also important here is the scenario where a technical person maintains a friend's or family member's computer. It should be easy for them to enable the root account and use it to recover/administer the machine.
The root account can be enabled by doing 'passwd root' from a root shell obtained via 'pkexec bash' or booting into single user mode or booting with init=/bin/bash or whatever.... Either way, maybe we shouldn't worry about that until it's relevant... we still have lots of work to do.
FWIW, I still disagree that the root password is what we want - in your usecase it is much better if the technical person just creates an user account on the system and adds that user to desktop_admin_r - that way he can login via ssh (using ssh keys) to that account instead of sending the root password through a lot of intermediate systems (albeit in a tunnel but MITM attacks aren't unheard of).
David
2009/8/13 David Zeuthen davidz@redhat.com:
1. If the desktop_admin_r group is non-empty, then users in the group are used for administrator authentication - see the polkit(8) man page for details: http://people.freedesktop.org/~david/pkexec-with-desktop-admin-r.png
Looks groovy.
but we probably want to allow installing trusted packages, install trusted updates and remove packages. Without asking for a password. Probably more - Richard?
The policy definitions are listed here, http://cgit.freedesktop.org/packagekit/plain/policy/org.freedesktop.packagek... along with rationale for each choice. Obvious ones to add to your list are:
org.freedesktop.packagekit.package-install org.freedesktop.packagekit.system-update org.freedesktop.packagekit.system-sources-refresh org.freedesktop.packagekit.system-network-proxy-configure
- For this to be really useful, we need the User Account Editor that Matthias wrote about here
Yes, without a GUI, I don't think many people will know anything about desktop_admin_r, and just complain that PackageKit now asks for passwords a lot more than it used to.
So, actions on my part:
1. Make the upstream packagekit policy actions more locked down 2. Add the 4 actions listed above to the PolicyKit rpm list 3. Profit?
Richard.
On Mon, 2009-08-17 at 17:21 +0100, Richard Hughes wrote:
2009/8/13 David Zeuthen davidz@redhat.com:
- If the desktop_admin_r group is non-empty, then users in the group
are used for administrator authentication - see the polkit(8) man page for details: http://people.freedesktop.org/~david/pkexec-with-desktop-admin-r.png
Looks groovy.
but we probably want to allow installing trusted packages, install trusted updates and remove packages. Without asking for a password. Probably more - Richard?
The policy definitions are listed here, http://cgit.freedesktop.org/packagekit/plain/policy/org.freedesktop.packagek... along with rationale for each choice. Obvious ones to add to your list are:
org.freedesktop.packagekit.package-install org.freedesktop.packagekit.system-update org.freedesktop.packagekit.system-sources-refresh org.freedesktop.packagekit.system-network-proxy-configure
Oh, you already seem to allow a lot of stuff out of the box. While neither of it looks like a root exploit maybe it would be wise to lock down further.
So I think we should at least require admin auth for installing packages and messing around with configuring proxies. It is probably fine to still allow signed system updates. Or maybe that involves configuring proxies as well? I don't know.
- For this to be really useful, we need the User Account Editor that
Matthias wrote about here
Yes, without a GUI, I don't think many people will know anything about desktop_admin_r, and just complain that PackageKit now asks for passwords a lot more than it used to.
That's my concern too. Maybe just add it as a FAQ for PackageKit as also to the Fedora release notes.
So, actions on my part:
- Make the upstream packagekit policy actions more locked down
- Add the 4 actions listed above to the PolicyKit rpm list
- Profit?
Sounds like a plan.
David
2009/8/17 David Zeuthen davidz@redhat.com:
So I think we should at least require admin auth for installing packages and messing around with configuring proxies. It is probably fine to still allow signed system updates. Or maybe that involves configuring proxies as well? I don't know.
No configuring or changing, this method just allows the daemon to use the session proxy data.
Richard.
desktop@lists.fedoraproject.org
-
Colin Walters -
David Zeuthen -
Lennart Poettering -
Richard Hughes