policykit introduction broke unix user groups

Bug #326135 reported by Onesimus on 2009-02-06
278
This bug affects 4 people
Affects Status Importance Assigned to Milestone
gnome-system-tools (Ubuntu)
Low
Unassigned
Nominated for Maverick by ceg
network-manager (Ubuntu)
Low
Unassigned
Nominated for Maverick by ceg
policykit (Ubuntu)
Undecided
Unassigned
Nominated for Maverick by ceg
policykit-1 (Ubuntu)
Low
Unassigned
Nominated for Maverick by ceg
ubuntu-meta (Ubuntu)
Low
Unassigned
Nominated for Maverick by ceg

Bug Description

I have set up a number of user accounts. On one of these accounts I adjusted the user privileges (System->Administration->Users and Groups->Properties->User Privileges). For one particular user I de-selected the two options:

    * Connect to Internet using a modem
    * Connect to wireless and ethernet networks

However, despite disabling access to the internet, the user is still able to connect to the internet through a wireless connection.

I am assuming that this is a security vulnerability, because the intention is to deny access and this doesn't occur.

I am using Ubuntu 8.10

----

Policykit has been introduced without supporting the unix groups. (used by admins and set up by the installer)

i.e. It is possible to create a policy that just said "yes" rather than "auth_*" where the default was "no", for anyone in the netdev group
so theiy could do it without a password.

-> we should ship PolicyKit config files that make use of these groups.

Marc Deslauriers (mdeslaur) wrote :

Did you try logging out and logging back in with that user when you tried it?

Marc Deslauriers (mdeslaur) wrote :

I can't see the "Properties" option in that dialog, could you please attach a screenshot?

Onesimus (joe-heaton) wrote :

I tried logging out and logging in. Also rebooting the machine. All to no avail.

A screenshot is attached of the User Settings window.

Onesimus (joe-heaton) wrote :

And of the Properties window

Onesimus (joe-heaton) wrote :

The network configuration tool allows a wireless connection to (presumably) apply as a system setting. I did wonder whether this may cause access to be granted and hence over-ride any settings that had been applied to a particular user.

See the screenshot for details.

Changed in policykit:
assignee: mdeslaur → nobody
status: Incomplete → Confirmed
Marc Deslauriers (mdeslaur) wrote :

It appears gnome-system-tools' "Connect to wireless and ethernet networks" adds the user to the "netdev" group, but NetworkManager doesn't use the netdev group. I'm not sure if that group is even actually used anymore. Should this be removed from gnome-system-tools?

affects: policykit (Ubuntu) → gnome-system-tools (Ubuntu)
Kees Cook (kees) on 2009-04-16
Changed in gnome-system-tools (Ubuntu):
importance: Undecided → Low
Milan Bouchet-Valat (nalimilan) wrote :

If these groups are really obsolete, we should not create them at all, they would disappear from users-admin.

Changed in ubuntu-meta (Ubuntu):
importance: Undecided → Low
Chris Coulson (chrisccoulson) wrote :

I'm fairly certain this group is no longer used any more. Privileges for networking should all be handled via Policykit now

Chris Coulson (chrisccoulson) wrote :

Although, I don't think network manager uses Policykit to restrict who can connect to wireless networks

ceg (ceg) wrote :

If policykit broke the desktop and unprivileged profiles this is a bug with policykit not being set up to honor those unix groups.

It seems to merely match all users in admin group to root.

Changed in ubuntu-meta (Ubuntu):
status: New → Invalid
Changed in network-manager (Ubuntu):
status: New → Confirmed
Changed in policykit-1 (Ubuntu):
status: New → Confirmed
Changed in network-manager (Ubuntu):
importance: Undecided → Low
Changed in policykit-1 (Ubuntu):
importance: Undecided → Low
James Westby (james-w) wrote :

This isn't a policykit bug. It's not getting involved at any stage of this as
far as I can see. If network-manager wants to call it to find out if the user can
connect to the internet then it can be involved, but until that point there is nothing
to fix in that package.

Thanks,

James

Changed in policykit-1 (Ubuntu):
status: Confirmed → Invalid

James: Do you know whether it's possible to allow users members of certain Unix groups to perform certain actions? In PolicyKit's docs, I can only find auth_self and auth_admin. If the program needs to check that the user is member of the group itself, the whole purpose of PolicyKit is destroyed. Or we should get rid of all those groups then...

On Fri, 12 Feb 2010 23:04:22 -0000, Milan Bouchet-Valat <email address hidden> wrote:
> James: Do you know whether it's possible to allow users members of
> certain Unix groups to perform certain actions? In PolicyKit's docs, I
> can only find auth_self and auth_admin. If the program needs to check
> that the user is member of the group itself, the whole purpose of
> PolicyKit is destroyed. Or we should get rid of all those groups then...

There is only auth_self and auth_admin, correct.

However, the system adminstrator can do overrides that are more
finegrained, down to the user/group level. I believe it would be
possible for them to create a policy (on top of an Ubuntu default system
that just said "yes" rather than "auth_*") where the default was "no",
but anyone in the netdev group could do it without a password.

Thanks,

James

OK. What I meant was that if we continue shipping these files, then we should also ship PolicyKit config files that make use of these groups - not let the sys admin fix that bug.

ceg (ceg) wrote :

> ...we should also ship PolicyKit config files that make use of these groups.

You're tres right, Milan. But you showed already twice "a desktop guy that actually learned/understands the *nix systems before not breaking them but hooking in to them" :) Kudos!

ceg (ceg) on 2010-03-12
summary: - User Privileges ignored
+ user:group privileges ignored
summary: - user:group privileges ignored
+ policykit breaking unix user/group privileges
ceg (ceg) on 2010-03-12
description: updated
tags: added: regression
summary: - policykit breaking unix user/group privileges
+ policykit introduction broke unix user/group privileges
Changed in policykit-1 (Ubuntu):
status: Invalid → Confirmed
ceg (ceg) on 2010-03-18
summary: - policykit introduction broke unix user/group privileges
+ policykit introduction broke unix user groups

policykit package is for PolicyKit < 1, and is obsolete. policykit-1 is used by most programs in Lucid.

Changed in policykit (Ubuntu):
status: New → Invalid
Maxim Levitsky (maximlevitsky) wrote :

This is very unpleasant feature that shouldn't be present in ubuntu.
It isn't security hole only.

For example adding user to 'audio' group breaks fast user switch, because the users audio continues to play
even when other user is active.

Since these unix groups seems to be abandoned, the right solution I think is to remove that settings page.
Users that have advanced needs (don't run desktop for example), can still happily use these settings

Maybe even better just allow user to edit the groups the user is in, but without misleading descriptions that are in place.

Scot Becker (scot-becker) wrote :

>Since these unix groups seems to be abandoned, the right solution I think is to remove that settings page.

Perhaps. That would take the bug away, but it wouldn't implement the missing feature. (Being able to create Desktop users who cannot tell the computer to make wireless or modem connections).

>Users that have advanced needs (don't run desktop for example), can still happily use these settings.

I'd be happy to do this manually but I don't know how (not that this is the place for you to tell me...)

Marc Deslauriers (mdeslaur) wrote :

The version of Ubuntu this bug applied to has been out of support for a long time now. Closing.

Changed in gnome-system-tools (Ubuntu):
status: Confirmed → Won't Fix
Changed in network-manager (Ubuntu):
status: Confirmed → Won't Fix
Changed in policykit-1 (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers