Exploitable to gain root access with non-priveleged user

Thanks for reporting this issue.

PolicyKit was written to give access rights to ordinary users without giving them root credentials. If your user had the right to administer users using PolicyKit, than this is expected behaviour.

Closing this bug. Please feel free to reopen it if you can reproduce it without your unprivileged user having PolicyKit rights.

Ah. I understand the distinction that you are making, and concede the point - but must take issue very strongly against this additional layer of permissions. Unix user permissions are very secure and straightforward, and imposing this second structure of (redundant) rights does not seem rational or wise.

Although on examination new users are -not- granted these permissions by default, this only mitigates the issue of granting unintended privileges for people who know that the application functions this way - counter to the security principles which, as far as I can tell, much of the community supports and expects.

To wit, I will either be un-installing policykit-gnome or removing chmod and sticking each one behind gksu in menu. Thank you for your time.

...Removing setuid, that is. Ahem.

I've reviewed this as well ( disclaimer: I am a friend of Kerin ) and I have to agree: this looks like a bad design decision. PolicyKit needs to have some way of synchronizing with system administrator privileges or there are just too many cooks in the kitchen. This is a classic example of lack of unity in design that Linux tends to suffer from. If PolicyKit has the ability to grant root access to users then it needs to behave like every other program that does so (like sudo). It should work through PAM just like everything else.

Policykit does use PAM, it's not clear to me what you mean by "work through
PAM".

Policykit is a framework that allows an app to query whether a
certain user is privileged to perform a certain "action". There is some
complexity to the model of whether a particular user is allowed to
perform a particular access at one time, but it can all be configured
by the system administrator.

Most often it is used for privilege escalation to allow users to be able to
perform certain tasks as root. In some ways this is similar to setuid
root executables, where the privilege is generally based on group
membership and permissions: if the user can execute the program
then they get root rights for whatever it is doing.

Because Ubuntu does not come with a root user by default we use
a feature of policykit to declare a certain group as the "admin" group,
we use "admin" for that. You can specify to policykit whether you want
an action to be available to members of this group, and most tools
do this, in particular the "Users and Groups" tool. Because the first user
of the system is added to this group they can use their own password
to gain these privileges, and so add users etc. Users in this group
are also given the ability to sudo to root by default, which is further
reaching than the policykit rights.

Granted, users in this group also have the rights to edit the policykit
policy via policykit, and so can grant themselves access to any parts
that are root-only (I'm not sure there are any on Ubuntu, but that's beside
the point), but the system administrator can stop this.

If you are worried about your systems then you can remove the "admin"
group from the policykit config. If it is just concern for Ubuntu that motivates
you then that is different. I think having the fine grained control offered
by policykit is valuable, and actually gives us a framework to *reduce* the
amount of code run as root. I think the admin group is worthwhile for the
usability, and perhaps even required with Ubuntu's lack of a root user by
default.

If your concern is specifically that you were able to do admin things while
the root user was locked, or that the users and groups tool allows non-root
users to edit the root account then we can discuss that.

Thanks,

James

Assuming that there is no root account is fine; however, it seems patently obvious that the best (and most foolproof, failsafe, and otherwise appropriate) method for checking the user's root privileges is to -not- have the application setuid as root by default and launch policykit through gksu(do) like many/most of the other administrative applications. Let me point out that this restriction would in no way hamper any functionality that already exists in gnome-policykit, while simultaneously increasing security significantly.

Yes, my concern is also that the users and groups tool allows non-root users to edit - and consequently assume - root access without needing to go through my system's inherent security measures.

I understand that a "stock" system - out of box - will not be affected since the default user both has sudo privileges and policykit rights. However, it is folly to let the user's security depend on such arbitrary factors - the scenario in which one sets up a machine for another person, creates an administrator account, and then disables sudo for the initial account comes to mind. The solution I propose would account for this perfectly.