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