1:28 p.m.
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&r...
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
1:55 p.m.
On Thu, 13.08.09 14:28, David Zeuthen (davidz(a)redhat.com) wrote:
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
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
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
2:37 p.m.
On Thu, 2009-08-13 at 20:55 +0200, Lennart Poettering wrote:
On Thu, 13.08.09 14:28, David Zeuthen (davidz(a)redhat.com) wrote:
> 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
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
2:41 p.m.
Hi,
This sounds pretty cool. I'm interested in some details:
On Thu, Aug 13, 2009 at 2:28 PM, David Zeuthen<davidz(a)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.
3:20 p.m.
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
4:24 p.m.
On Thu, Aug 13, 2009 at 4:20 PM, David Zeuthen<davidz(a)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.
4:51 p.m.
On Thu, 2009-08-13 at 17:24 -0400, Colin Walters wrote:
On Thu, Aug 13, 2009 at 4:20 PM, David
Zeuthen<davidz(a)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
11:21 a.m.
2009/8/13 David Zeuthen <davidz(a)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.packa...
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.
11:33 a.m.
On Mon, 2009-08-17 at 17:21 +0100, Richard Hughes wrote:
2009/8/13 David Zeuthen <davidz(a)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.packa...
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:
1. Make the upstream packagekit policy actions more locked down
2. Add the 4 actions listed above to the PolicyKit rpm list
3. Profit?
Sounds like a plan.
David
11:47 a.m.
2009/8/17 David Zeuthen <davidz(a)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.
5359
days inactive
5363
days old
desktop@lists.fedoraproject.org
9 comments
4 participants
participants (4)
-
Colin Walters -
David Zeuthen -
Lennart Poettering -
Richard Hughes