On 2/24/20 1:21 PM, Daniel Abrecht via Dng wrote:
Hi
I would like to add my point of view to the polkit debate.
I don't think polkit is bad or unnecessary, it simply has a completely
different usecase/scope than sudo has.
sudo is for starting a process as an other user provided some preconditions
(group/user allowed to use it, supplied arguments allowed, etc.) are met.
And it can retain or restrict some resources inherited from the parent process
(such as environment variables, for example).
Therefore, the use case is to allow some users to execute certain commands in
certain ways with certain resources.
I know polkit less well, but my current understanding is, that polkit is for
managing access to stuff on dbus.
So next, why is dbus needed?
dbus is a message bus. There usually is one for the whole system, and one for
each session.
There are various uses and missuses for it, but I think the most crucial things
are:
* Notify any process interested in something of these things.
* Tell other programs which can do something to do something.
This can be useful for various things, for example:
* A program may want to now if a device got rotated, so it can rotate a
screen.
* A wlan management gui may want to tell it's daemon that it shall connect to
a wlan, and it may want to know what connections it already has and manages.
* A phone call application may want to ring when a call arrives, or it may
want to let the user initiate a call.
Now, those examples are mainly things that would need the system bus. I
couldn't come up with a good example solely within a user session/bus, but I'm
sure these exist too, especially because dbus doesn't need a graphical session.
And with that, back to polkit. It'd be bad if just everyone/everything could do
system level stuff, so per default, noone can. But that would make dbus useless
for a lot of things.
This is the problem polkit is there to solve, there are config files specifying
who (user, group, etc.) can see/use which methods calls, signals/messages, etc.
Hi,
Yes inter-process communication can be useful.
Without dbus, applications & daemons could do similar things using unix
sockets. However, then, every application would need their own socket, permission
management, configs, etc. This would have the same security implications as just
using dbus, which also just uses unix sockets, but would leave a bigger attack
surface, and a lot of scattered security critical configs with different formats.
Now, there is also the approach of using a suid binary for the privileged
stuff. As a good and bad thing, just like sudo, this can't escape a container,
unlike a unix socket passed to one could. However, it would leave the problem
of a bigger attack surface, and a lot of scattered security critical configs
with different formats, and is very difficult to get right.
Why is the attack surface bigger? Bigger than polkit running a daemon as root,
an
agent as the user and having config files scattered all over the place?
All things considered, I think for the purpose of interacting with system level
daemons/services and managing related permissions, especially in cases more
complex than simply shutting down the system for example, dbus + polkit is a
very nice solution, especially considering the alternatives. It does have some
flaws, though, such as noone knowing how to correctly configure it, for example.
Yes I fully agree this is difficult to configure even more so if you use more
than one DE
and I see the security risk in this complexity, long cryptic config files
that compell you to use sudo or su to get things working.
Regarding pkexec, I think this thing is an abomination. Starting a process is
absolutely not something which should be done in a way completely disregarding
resources and restrictions of the spawning process. It's kind of useful for
checking if polkit works at all, but aside from that, I recommend getting rid
of it as fast as possible.
Regarding gksudo, I think it's intended use case is an awful thing as well. The very Idea of asking for a users password for starting a more privileged process is a bad one. It means that if the user account is breached, as soon as sudo or gksudo is used to obtain root, it could have been replaced (z.B. by changing the PATH, setting an alias, etc.) by an attacker to get the password instead, and then compromise the rest of the system. In my opinion, sudo should always be used in such a way as to work without password,
and only for known "safe" commands. For everything else, it'd be much better to
just log in on a tty as root. Same goes for su.
for sudo only if set
user ALL=(ALL:ALL) ALL
or if the user is added to the sudo group
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
if used for single commands it should not be a problem
unless you allow to open a root xterm....
To replace su or sudo binary you need root so at this point
the system is already compromised.
The use with no password solves one problem but creates others
like everybody being able to wreck the system with synaptic
or gparted as soon as they find an unattended desktop.
Don't want my mom to use synaptic......just mail and browser.
Ciao,
Tito
One last, only partially related thing. Does anyone know how to get polkit
agents working properly? If I start `lxqt-policykit-agent`, for example, pkexec
won't work. If I start it as `su -c 'lxqt-policykit-agent'`, it does, but I'm
pretty sure that's not the right way to do this. I'm currently on devuan
beowulf, but I think debian users may have similar problems, I think
systemd/logind people may have broken something in polkit...
Regards,
Daniel Abrecht
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
