I am running OpenSuse Release 12.3 (64-bit) / Linux 3.7.10-1.16-desktop / GNOME 3.6.2 on my desktop.
I have just noticed that the Software Update utility installs software updates (when I tell it to, of course!) without asking for the root password. Is that normal? Or, is that a security issue? I seem to remember that this was not the case with earlier configurations, but I might be mistaken.
On the other hand, if I start Yast in order to install software, it asks for the root password. Forgive me if I am raising a red herring.
I guess that you mean Aper/PackageManager with “the Software Update utility” and not YaST/zypper.
And yes Apper/PackageManager does not ask for the root password for updates (but it does for installing new packages). And yes, some see this as a security violation.
If you decide this is a security violation depends manily on how you see the relation between your end-user(s) and you as the system manager. When the end-user can be trusted (e.g. because he is you, if you understand what I mean) for updates, then this is OK. When you think you as system manager want coomplete control ovr what happens with the installed software (e.g. because you do not want a new kernel instlled on a system that can not be booted soon after), you will not allow this behaviour.
I think this “feature” is designed with a system used by only on physical user in mind (much like an MS Windows system). But it is not obvious that it is a fature in a multi user operating system like Linux. The main problem here is that such a thing pops up with a new release without warning exising (for a long time) system managers that a hole is blown in their defence when they do not act.
How to stop this behaviour?
I guess it is configured in the desktop permissions, though i do not know details.
deinstall Apper (and maybe also Package manager). Many here did.
Yes, I mean the application called Software Update, that appears in the list of Gnome applications.
What I do not understand is how it can load files into folders to which only root has access! Not even I as sole user can do that. Is there a ‘back door’ somewhere?
It gets the permission from polkit. This can be configured in /etc/polkit* and /etc/sysconfig/security (PERMISSION_SECURITY).
The default security setting is “easy local” where the permissions for updating software with PackageKit are “auth_admin_keep_always:auth_admin_keep_always:yes” since 12.2, which means the currently logged in user on the active console may install updates, all other users (remote ones f.e.) need the root password.
If you change PERMISSION_SECURITY to “secure” f.e., even the locally logged in user would need the root password for installing updates, but also for other stuff like mounting USB drives a.s.o.
You (better: the system administrator) can override specific rules in /etc/polkit-default-privs.local, you have to run “set_polkit_default_privs” after you changed that file.
You are correct, but I will formulate this more to the point. A process has an owner and group and can only do things to to a file when the permission bits for the file’s owner/group/world match wiith the process’s.
Now look at a progam like su:
henk@boven:~> ls -l $(which su)
-rwsr-xr-x 1 root root 44256 23 jan 14:04 /usr/bin/su
henk@boven:~>
You see the s on the place where you would expect an x (su being an executable program). This means that su is a “set-uid” (or suid) program. Which means that whoever executes that program, the process that results of it will not use the uid of the starting user, but the uid of the owner of the file /usr/bin/su. And that owner is root.
Thus, when you , as end-user, call
su
it will run “under root”.
This means in the first place that suid programs, specialy when their owner is root, should be programmed very security consious. Because such a program, can do everything as root and a compromised su file can break your system at will. This is one of the reasons while the permission bits of e.g. /usr/bin should be tight, to be certain that programs like su can not be replaced.
Well, the su program does allready exist for more hen 40 years, thus we may assume that it is OK.
I hope you now understand that it is su that does not start what you ask from it, before you identfy yourself with the root password (and not some magic). Same with sudo, but sudo can be configured to ask for the root password, the end-user’s password, or no password, for different tasks. And thus your update program does about the same. And the configuration that tells it to ask or not to ask for a password is in polkit. But the update process itself certainly runs “under root”. Else it can not update system files. As you assume correctly.
The process does seem to be somewhat elusive! Using the Gnome system Monitor, I see that a process called ‘gpk-update-viewer’ is started when I start the ‘Software Update’ application. If I now use pstree from a terminal, there is nothing I recognise similar to that. I do notice, however, that the Software Update window closes automatically after about a minute, even if I do not acknowledge the message saying that there are ‘no software updates at this time’.
Now, I believe, I have to find an application called ‘gpk-update-viewer’ in the file system. Right?
No, the updates are done by packagekitd (file /usr/lib/packagekitd) which runs as root. The applet only asks the daemon to install the updates. The daemon then asks polkit in turn to check that the updates are allowed or not.
packagekitd quits itself after some idle time (so it doesn’t block YaST/zypper), so you won’t see it running most of the time.
Maybe I would use YaST > Software > Software manager, type gpk-update-viewer in the Search filed and check the “Povides” box. It should offer you the package that contains the file. Then, lower right, use the tab for the file list to see where it is located.
I guess gpk means Gnome Pakage Kit.
I do not know why you want to find it… Is it pure curiousity or do you want to do something with it?
I want to find out what gets started by the SW update App. Whatever it is, it has all the rights to install software on my computer and that makes me nervous.
Actually, wolfi323 has also provided some good info as well, so I think my concerns are allayed.
Yes, wolfi323 points to another way to communicate between a user aplication and a root process. IInthis case contactinmg a daemon. That works e.g. over the network, where you, using a browser process running with your uid, contacts a HTTP server running with uid www (either on the same or another system). And that works also for a lcal connection to a local process.
No it has not. Polkit takes care of that.
In the default setup a user that is directly logged in is allowed to install updates (and only that; you need the root password if you want to install a new package). Other users (f.e. logged in remotely) need the root password even for updates.
If everybody should have to enter the root password for installing updates, you could change your security settings to “secure”, but that would cause root password requests for many other things as well, f.e. mounting USB drives/CDs/DVDs, refreshing the software repos which PackageKit does once a day, connecting to a WLAN/WiFi, and so on.
If you just want stricter rules for installing updates, add the following line to /etc/polkit-default-privs.local and run “/sbin/set_polkit_default_privs” as root:
Other values you could use instead of “auth_admin_keep” include:
“yes”: always allowed
“no”: never allowed
“auth_admin”: only allowed if root password is entered
“auth_self”: only allowed if user password is entered
To the auth_* values you can also add “_keep” (password is remembered for 5 minutes) and “_keep_always” (password only has to be entered once per session.
The real work is done by “packagekitd” which is running as root.
The desktop application communicates with packagekitd. Then “packagekitd” asks “polkitd” whether to allow this. In turn “polkitd” consults with “console-kit-daemon” to determine whether you are logged in at the console. It then uses the polkit rules to decide whether to allow.
If you don’t want to allow this, you can change the polkit rules, though getting that right can be tricky.
Or just uninstall the update application. I’m not sure, but maybe it is safe to uninstall “packagekitd”.
I find it hard to believe that this is not a security issue. “Packagekitd”, running as root, did not ask for my root password to start. “polkitd” should find that I (as ‘root’ administrator) am not logged in at the console (because I am not!) and forbid the action or at least ask for root permission.
I am now running OpenSuse 13.1. “packagekit” seems to be even more insistent in that, even if I do not click on the ‘install now’ button, it will begin the installation process anyway. Even after I changed the PERMISSION_SECURITY from the default ‘local easy’ to ‘secure’, “package kit” can still install updates without asking for the root password.
As I say, I find it hard to escape the thought that there is a security issue here, (although, if I am honest, as a ‘normal’ user, I would not know which criteria would apply for not installing the updates offered!
So what?
Many other daemons are running as root and don’t ask you for your root password to start… Would be a bit cumbersome to boot otherwise…
And btw, the daemon is only running if the update applet (or pkcon, the command line client) requests an action. It shuts itself down again if idle.
“polkitd” should find that I (as ‘root’ administrator) am not logged in at the console (because I am not!) and forbid the action or at least ask for root permission.
How are you logged in then?
If you are logged in as normal user on your system, polkit will grant you the right to install updates, since that’s what it’s configured to do by default.
I am now running OpenSuse 13.1. “packagekit” seems to be even more insistent in that, even if I do not click on the ‘install now’ button, it will begin the installation process anyway.
No, it won’t. Unless you manually configured it to do that.
It may refresh the package list automatically though.
Even after I changed the PERMISSION_SECURITY from the default ‘local easy’ to ‘secure’, “package kit” can still install updates without asking for the root password.
Have you run “/sbin/set_polkit_default_privs” as root afterwards? This is needed for the change to take effect.
If you set PERMISSION_SECURITY to ‘secure’ it should ask you for the root password, since /etc/polkit-default-privs.restrictive contains the line:
On 2013-12-10 10:26, hnimmo wrote:
> I am now running OpenSuse 13.1. “packagekit” seems to be even more
> insistent in that, even if I do not click on the ‘install now’ button,
> it will begin the installation process anyway. Even after I changed the
> PERMISSION_SECURITY from the default ‘local easy’ to ‘secure’, “package
> kit” can still install updates without asking for the root password.
Remove it.
On the systems where there is a responsible admin, packagekit should not
ever run. Users do not need to know there are updates, even less be
offered to install them.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
