Security problem with Super User Authorization

Asked by smurf

Ubuntu Xenial 16.04 Mate.

On my system I have 3 accounts (me, my wife and my son), My account is the only that can use SUDO, the others are desktop users.
I need to limit the access to my son (5 years old), so I had to put the password to my login, but my password was very strong: large and complicate. Otherwise I need to use sometimes SUDO (truecrypt, rsync with other devices, etc.).
In order to simplify my login and keep the ability to use SUDO I activated the "targetpw" flag in sudoers, so now my login password is quite easy and ROOT account has the strong password.
It works, programs like synaptic, sudo, gksu and others accept the root password, but I found a very very strange behaviours in some programs, for example:

a) users-admin
b) gnome-language-selector
c) lightdm-gtk-greeter-settings-pkexec

Those programs perform admin tasks and I suppose that when they ask for the password authorization they need the root password.
No! They want my personal account password, the root password is not accepted.

I think that this is not right, because my system now has a security weakness, and I don't know how many other programs have the same behaviour. The problem could be a serious security breach.

I wish to report a bug, but apport doesn't accept a bug for sudo and I don't know which package/packages to indicate.

Can somebody help me?

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Solved by:
smurf
Solved:
Last query:
Last reply:
Revision history for this message
Manfred Hampl (m-hampl) said :
#1

I do not see any advantage in setting targetpw in the sudoers file; in my opinion especially the aim to use a less secure password that was set on the 'root' account is nonsense.

If you want to create a bug against the sudo package and cannot do this with apport, then you might us the Launchpad web pages: open https://launchpad.net/ubuntu/+source/sudo/+bugs and use the "report a bug" link on the top right corner, or directly use https://launchpad.net/ubuntu/+source/sudo/+filebug

Revision history for this message
Oliver R. (oliverr) said :
#2

I have the same problem and no answer yet, but maybe some clues towards one.

I'm quite sure it has nothing to do with sudo. At least in my case sudo always asks for the root password due to the "targetpw" option in /etc/sudoers.

The three examples you name use the policy kit, namely the command pkexec to gain root privileges. This is independent of sudo. So somehow one has to make the policy kit ask for the root password too–at least for critical tasks (gparted, terminal, file manager, etc.). But so far I have no idea how to do this. The policies are stored in /usr/share/polkit-1/actions.

Revision history for this message
Oliver R. (oliverr) said :
#3

Well, 5 minutes later I stumbled over something like an answer:

Just move the file /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf out of the way:

sudo mv /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf /etc/polkit-1/

Then only the file /etc/polkit-1/localauthority.conf.d/50-localauthority.conf is left in the directory, which contains the line:
AdminIdentities=unix-user:0

So only the root user (uid 0) may be used for authentication.

As I haven't tested this deeply, please post any unwanted side-effects. I expect that now all privileged tasks (even non-dangerous ones) require the root password.

Revision history for this message
Oliver R. (oliverr) said :
#4

Instead of moving 51-ubuntu-admin.conf out of the may, more elegantly one copies 50-localauthority.conf to a higher number, which overrides any previous assignments to AdminIdentities:

sudo cp -p /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf /etc/polkit-1/localauthority.conf.d/60-root.conf

This way, later system updates won't effect this.

Revision history for this message
Oliver R. (oliverr) said :
#5

Typo! It sould read:

sudo cp -p /etc/polkit-1/localauthority.conf.d/50-localauthority.conf /etc/polkit-1/localauthority.conf.d/60-root.conf

Revision history for this message
smurf (luca-dgh) said :
#6

In Bugs Forum they answered me and I made the trick.
https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1643931