Changes to polkit-desktop-policy

[Matthias Clasen]

Recently,

we noticed that firstboot now has a checkbox to give admin privileges to
the first user. It does so by adding the user to the wheel group, which
unfortunately, doesn't do much [1] for PolicyKit, which was using a
different group to identify the Administrator role.

To fix this disconnect, David, Bill and I decided that we should change
the PolicyKit policy that we ship to use the wheel group for this
purpose as well. At the same time, we are dropping the
not-really-implemented concept of 'Supervised' user. It can come back
when we have a working, integrated solution for parental controls.

So, very soon, in F15, we will have only administrators (who are in the
wheel group), and regular users (who are not). The desktop_admin_r and
desktop_user_r groups will no longer be created or used. The changes to
the PolicyKit desktop policy can be seen here: [2].

Just thought I should mention this here in case anybody else was doing
anything with the desktop_admin_r or desktop_user_r groups and related
PolicyKit permissions.

Matthias

[1] https://bugzilla.redhat.com/show_bug.cgi?id=688363
[2]
http://pkgs.fedoraproject.org/gitweb/?p=polkit.git;a=commitdiff;h=9fa422d544...

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/17/2011 12:21 PM, Matthias Clasen wrote:
> Recently,
>
> we noticed that firstboot now has a checkbox to give admin privileges to
> the first user. It does so by adding the user to the wheel group, which
> unfortunately, doesn't do much [1] for PolicyKit, which was using a
> different group to identify the Administrator role.
>
> To fix this disconnect, David, Bill and I decided that we should change
> the PolicyKit policy that we ship to use the wheel group for this
> purpose as well. At the same time, we are dropping the
> not-really-implemented concept of 'Supervised' user. It can come back
> when we have a working, integrated solution for parental controls.
>
> So, very soon, in F15, we will have only administrators (who are in the
> wheel group), and regular users (who are not). The desktop_admin_r and
> desktop_user_r groups will no longer be created or used. The changes to
> the PolicyKit desktop policy can be seen here: [2].
>
> Just thought I should mention this here in case anybody else was doing
> anything with the desktop_admin_r or desktop_user_r groups and related
> PolicyKit permissions.
>
> Matthias
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=688363
> [2]
> http://pkgs.fedoraproject.org/gitweb/?p=polkit.git;a=commitdiff;h=9fa422d544...

Are we turning on the wheel group in sudo?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk2CRNwACgkQrlYvE4MpobPe7gCbBeySV4CnRscKouJCg3EWUdCC
> R6QAnjQ+sJggqFtHaiFNXFOGJvgij0pH
> =1IZf
> -----END PGP SIGNATURE-----

[Colin Walters]

On Thu, Mar 17, 2011 at 1:29 PM, Daniel J Walsh  wrote:
> Are we turning on the wheel group in sudo?

It would clearly match doing so for pkexec, but would then be bizarre
because the Fedora installer still asks you to make up a root
password.  The whole thing is really a mess without any plan for where
things are going.

Is there any plan, anywhere?  Where was the design behind firstboot
adding the checkbox?

[Bill Nottingham]

Colin Walters ([e-mail]) said:
> On Thu, Mar 17, 2011 at 1:29 PM, Daniel J Walsh  wrote:
> > Are we turning on the wheel group in sudo?
>
> It would clearly match doing so for pkexec, but would then be bizarre
> because the Fedora installer still asks you to make up a root
> password.  The whole thing is really a mess without any plan for where
> things are going.
>
> Is there any plan, anywhere?  Where was the design behind firstboot
> adding the checkbox?

Looking now, it stems from https://bugzilla.redhat.com/show_bug.cgi?id=462161;
in that bug it mentions:

- having the checkbox to add to 'Administrator' group
- changing the polkit config
- changing the usermode config to use this

So, it looks like the second two bits weren't properly cloned/communicated.
Design of this appears to have been 'firstboot maintainer + people CC'd on
the bug.' Changing the root password screen wasn't mentioned as part of that
plan; note that that's at an entirely different portion of the workflow, and
given that firstboot does not run on all installs, leads to problems if you
drop it entirely (how do you log in?)

Bill

[Colin Walters]

On Thu, Mar 17, 2011 at 1:57 PM, Bill Nottingham  wrote:
> So, it looks like the second two bits weren't properly cloned/communicated.
> Design of this appears to have been 'firstboot maintainer + people CC'd on
> the bug.'

Okay...
> Changing the root password screen wasn't mentioned as part of that
> plan;

The point is that that in the default flow now, you get both; and
there is no plan to change this; correct?
> note that that's at an entirely different portion of the workflow, and
> given that firstboot does not run on all installs, leads to problems if you
> drop it entirely (how do you log in?)

Of course, I know why firstboot was created, and we've talked in the
past about basically running it inside Anaconda so in the case where
you *aren't* booting a pre-imaged system it is saner.  But that's not
quite the point - it's really not hard to change our software
implementation.  The hard part is having a plan for what the
implementation should be, and that's my above question.

[Chris Adams]

Once upon a time, Colin Walters  said:
> The point is that that in the default flow now, you get both; and
> there is no plan to change this; correct?

If you don't have a root password, how do you log in for single-user
mode, manual fsck, etc.?  AFAIK those only prompt for the root password,
not a username.

[Colin Walters]

On Thu, Mar 17, 2011 at 2:22 PM, Chris Adams  wrote:
> Once upon a time, Colin Walters  said:
> > The point is that that in the default flow now, you get both; and
> > there is no plan to change this; correct?
>
> If you don't have a root password, how do you log in for single-user
> mode, manual fsck, etc.?  AFAIK those only prompt for the root password,
> not a username.

Sorry, I didn't want a long thread at the moment to try to create the
plan; if there isn't one, for Fedora 15, it just needs some sort of
release note:

"You can now easily enable both sudo and pkexec for the first user
created via a checkbox; see the manual pages for each tool."

Actually, we'd also need to mention the changes in the
polkit-desktop-policy, which looks like it boils down to "Change the
system time" and "Mount internal file systems"?

Well except it *would* for the first, but the clock mechanism moved to
org.gnome.settingsdaemon.datetimemechanism.

[Colin Walters]

On Thu, Mar 17, 2011 at 2:22 PM, Chris Adams  wrote:
> Once upon a time, Colin Walters  said:
> > The point is that that in the default flow now, you get both; and
> > there is no plan to change this; correct?
>
> If you don't have a root password, how do you log in for single-user
> mode, manual fsck, etc.?  AFAIK those only prompt for the root password,
> not a username.

I will follow up briefly here to say that this kind of issue comes
down to the fact that thinking in terms of users and passwords is
wrong - you need to step back and think in terms of "deployment
targets", which boil down to "(at least one) user owns machine"[1],
"timesharing unix server", "lab workstation" and "kiosk" mainly.

For the user-owns-machine target, we obviously have to provide some
hatch for them to "do whatever"; currently that's the root password.
But the root password is silly for this model because they can just
boot with "init=/bin/sh" and do whatever.  So fsck would need to
recognize this and probably just refuse to boot by default, but
obviously it could be configurable.

Presently we have a big mess of tools which are obviously all
configurable, and I'd say the target is vaguely "lab workstation",
except for a few PolicyKit files which move the default OS install
closer to "user owns machine".

[1] A lot of people call this "single user laptop/desktop", but in
fact this target can be multi-user, just as long as least one person
owns the hardware, and it has nothing to do with laptops or desktops.

[Miloslav Trmač]

Colin Walters píše v Čt 17. 03. 2011 v 13:45 -0400:
> On Thu, Mar 17, 2011 at 1:29 PM, Daniel J Walsh  wrote:
> > Are we turning on the wheel group in sudo?
>
> It would clearly match doing so for pkexec, but would then be bizarre
> because the Fedora installer still asks you to make up a root
> password.  The whole thing is really a mess without any plan for where
> things are going.
>
> Is there any plan, anywhere?  Where was the design behind firstboot
> adding the checkbox?

Having such a facility would probably make life for quite a few users
easier - but the interface does need more thought.

The checkbox currently reads: "Add to Administrators group".

* There is no "Administrators" group, users won't know what has
  actually happened.

* This concept new, and not familiar to any group of existing users:

- UNIX users know what a "group" is, but never heard of an
    "Administrators" group (n.b. with a capital :) )

- Windows users know what an "Administrators group" is, but
    it behaves differently: "Why can't I browse to /var/log/audit
    with Nautilus?  It does not let me view the directory, and does
    not present me with an option to override this.  I'm an
    administrator!"

- I don't really know about newbies - I suspect something like "Huh,
    administrator?  This is my home machine.  Do I check this for my
    computer-smart brother-in-law?  Or will this make me an
    administrator at work if I bring this computer into the office?"

We can make the UNIX users happy easily enough, by changing the label to
"Add to wheel group", but that makes the user experience for others even
worse.

Also, if this checkbox is in firstboot, it probably needs to be in
system-config-users as well.

This probably should have been a "proper" F15 feature.
    Mirek

[Nathanael D. Noblet]

On 03/17/2011 12:41 PM, Miloslav Trmač wrote:
> Colin Walters píše v Čt 17. 03. 2011 v 13:45 -0400:
> > On Thu, Mar 17, 2011 at 1:29 PM, Daniel J Walsh  wrote:
> > > Are we turning on the wheel group in sudo?
> >
> > It would clearly match doing so for pkexec, but would then be bizarre
> > because the Fedora installer still asks you to make up a root
> > password.  The whole thing is really a mess without any plan for where
> > things are going.
> >
> > Is there any plan, anywhere?  Where was the design behind firstboot
> > adding the checkbox?
>
> Having such a facility would probably make life for quite a few users
> easier - but the interface does need more thought.
>
> The checkbox currently reads: "Add to Administrators group".
>
> There is no "Administrators" group, users won't know what has
>  actually happened.
>
> This concept new, and not familiar to any group of existing users:
>
> UNIX users know what a "group" is, but never heard of an
> "Administrators" group (n.b. with a capital :) )
>
> Windows users know what an "Administrators group" is, but
> it behaves differently: "Why can't I browse to /var/log/audit
> with Nautilus?  It does not let me view the directory, and does
> not present me with an option to override this.  I'm an
> administrator!"

In addition to the above... many people (in the windows world) are being 
taught to setup their own 'Admin' user to do the installation / 
management stuff so that virus' can't get additional rights etc... They 
could transfer that same assumption...

[Bill Nottingham]

Miloslav Trmač ([e-mail]) said:
> > It would clearly match doing so for pkexec, but would then be bizarre
> > because the Fedora installer still asks you to make up a root
> > password.  The whole thing is really a mess without any plan for where
> > things are going.
> >
> > Is there any plan, anywhere?  Where was the design behind firstboot
> > adding the checkbox?
>
> Having such a facility would probably make life for quite a few users
> easier - but the interface does need more thought.
>
> The checkbox currently reads: "Add to Administrators group".
>
> There is no "Administrators" group, users won't know what has
> actually happened.
>
> This concept new, and not familiar to any group of existing users:
>
> UNIX users know what a "group" is, but never heard of an
> "Administrators" group (n.b. with a capital :) )
>
> Windows users know what an "Administrators group" is, but
> it behaves differently: "Why can't I browse to /var/log/audit
> with Nautilus?  It does not let me view the directory, and does
> not present me with an option to override this.  I'm an
> administrator!"
>
> I don't really know about newbies - I suspect something like "Huh,
> administrator?  This is my home machine.  Do I check this for my
> computer-smart brother-in-law?  Or will this make me an
> administrator at work if I bring this computer into the office?"
>
> We can make the UNIX users happy easily enough, by changing the label to
> "Add to wheel group", but that makes the user experience for others even
> worse.

Yeah, that's not really a good option. Perhaps rename it to
'Make user an administrator'?

The current implications of this are:
- user will have sudo access (can disable by editing sudoers)
- user will have pkexec access (can disable by adding PK overrides)
- user will be able to perform:
  - disk operations (via udisks)
  - clock operations (via gnome)
  without a password (can disable by adding PK overrides)
- any polkit operation that asks for 'admin' access will ask for the user
  password, not the root password (can disable by adding PK overrides)

There's an open bug to also have the default config-util setting for
consolehelper to ask for the user's password instead of the root password,
for wheel group members. This would be consistent with sudo/pkexec
above.
> Also, if this checkbox is in firstboot, it probably needs to be in
> system-config-users as well.

It's currently in firstboot and the gnome control-center user and
group tool (where it's an option for the account type.)

Given how system-config-users is implemented and designed, I'm not
sure it makes sense as a checkbox there. s-c-users is essentially
shown as a GUI editor to the passwd/group files; everything is
presented literally. Adding a checkbox that is implemented semantically
doesn't make sense in that interface.
> This probably should have been a "proper" F15 feature.

Not really disagreeing there.

Bill

[Matthew Miller]

On Thu, Mar 17, 2011 at 03:30:23PM -0400, Bill Nottingham wrote:
> > This probably should have been a "proper" F15 feature.
>
> Not really disagreeing there.

Yeah. It's something I've been agitating for since way before there _was_ a
features process [1][2], and some of the pieces are just kind of falling
into place without the current proper framework.

Might it be wise to put the brakes on this and make it a F16 feature?

1. http://lists.fedoraproject.org/pipermail/devel/2004-December/064580.html
2. http://www.redhat.com/archives/fedora-desktop-list/2005-March/msg00002.html

[Miloslav Trmač]

Matthew Miller píše v Čt 17. 03. 2011 v 18:44 -0400:
> On Thu, Mar 17, 2011 at 03:30:23PM -0400, Bill Nottingham wrote:
> > > This probably should have been a "proper" F15 feature.
> >
> > Not really disagreeing there.
>
> Yeah. It's something I've been agitating for since way before there _was_ a
> features process [1][2], and some of the pieces are just kind of falling
> into place without the current proper framework.
>
> Might it be wise to put the brakes on this and make it a F16 feature?

If both the installation process and gnome-control-center support the
"administrator" concept, I think this is in good enough shape for F15,
code-wise.  We just need to handle a few loose ends:

* Documentation.  Making "wheel" essentially equivalent to root is an
important change in the default setup for anyone that currently uses the
"wheel" group, with significant security implications.  It needs to be
documented and announced as such.

* Translations.  If we want to change the firstboot text, translations
have to be dealt with - we are currently past the feature freeze, and
the string in firstboot is highly visible.

Does anyone want to own this not-quite-a-feature?  (I'm afraid I'm not
volunteering.)
Mirek

[Chris Smart]

On Fri, Mar 18, 2011 at 3:21 AM, Matthias Clasen  wrote:
> Recently,
>
> we noticed that firstboot now has a checkbox to give admin privileges to
> the first user. It does so by adding the user to the wheel group, which
> unfortunately, doesn't do much [1] for PolicyKit, which was using a
> different group to identify the Administrator role.

I assume that this will not be changed for F14? So the desktop_admin_r
configuration will remain?

Thanks,
-c

[Matthias Clasen]

On Fri, 2011-03-18 at 13:32 +1100, Chris Smart wrote:
> I assume that this will not be changed for F14? So the desktop_admin_r
> configuration will remain?

There are no plans to change this in F14.

[Kevin Kofler]

Matthias Clasen wrote:
> The changes to the PolicyKit desktop policy can be seen here: [2].

[snip]
> [2] http://pkgs.fedoraproject.org/gitweb/?p=polkit.git;a=commitdiff;h=9fa422d544...

Quoting from that file:
> Action=org.gnome.clockapplet.mechanism.*;org.freedesktop.RealtimeKit1.*;org.freedesktop.udisks.filesystem-mount-system-internal

Can we please add "org.kde.kcontrol.kcmclock.save"? If we allow setting the
clock from GNOME, we should allow it from KDE as well. :-)

Kevin Kofler