policykit introduction broke unix user groups

[Onesimus]

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)]

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

[Marc Deslauriers (mdeslaur)]

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

[Onesimus (joe-heaton)]

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)]

And of the Properties window

[Onesimus (joe-heaton)]

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.

[Marc Deslauriers (mdeslaur)]

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?

[Milan Bouchet-Valat (nalimilan)]

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

[Chris Coulson (chrisccoulson)]

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)]

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

[ceg (ceg)]

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.

[James Westby (james-w)]

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

[Milan Bouchet-Valat (nalimilan)]

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...

[James Westby (james-w)]

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

[Milan Bouchet-Valat (nalimilan)]

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)]

> ...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!

[Milan Bouchet-Valat (nalimilan)]

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

[Maxim Levitsky (maximlevitsky)]

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)]

>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)]

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