[gentoo-user] Re: sans-dbus was: gnome intrusion?

[Kai Krakow <hurikhan77@gmail.com>]

Am Thu, 17 Nov 2016 04:08:31 -0500
schrieb Rich Freeman <rich0@gentoo.org>:

> On Thu, Nov 17, 2016 at 2:56 AM, Ian Zimmerman <itz@primate.net>
> wrote:
> > On 2016-11-16 20:48, Rich Freeman wrote:
> >  
> >> Policykit also lets you do stuff like saying this user is allowed
> >> to restart this service, but not do anything else, and so on,
> >> using a configuration which is flexible and works across different
> >> applications/etc.  
> >
> > I'm curious what you mean by "service" here.  Surely not the things
> > managed by rc-service, only root can touch them, right?  Or regular
> > users via sudo, and then sudo config restricts what they can do.
> >
> > I'm _guessing_ you mean desktop services like gnome-settings, and my
> > retort is, I don't have any of those, and I never will.
> >  
> 
> No, I mean services as in stuff like apache, gnome, and so on.
> However, this was probably not a great example as it looks like none
> of the service managers actually support policykit for this right now,
> which means that only root can use these dbus commands.

I think systemd supports it, tho I don't know how granular that can be
made. Ideally, on a systemd machine, also desktop services are managed
by a user instance of systemd. In this case, the user is already able
to manage all these services. But most DEs still bring their own
service manager (like kded in KDE I think), managed through dbus with
an incompatible interface to systemd. The only systemd-native services
in my DE is currently pulseaudio, invaded by a few service brought by
Gnome components, including the aforementioned at-spi-dbus-bus.service
which I masked. Of course, dbus is part of this systemd user instance.

I've just taken another look at "systemctl --user status" and it looks
like more and more KDE services are also started from systemd now
through dbus activation. I wonder which components I could remove
from /etc/xdg/autostart so these are only started on demand through
dbus activation.

In the end, systemd /can/ make your system slimmer by starting services
(user and system) only on demand through dbus activation (or socket
activation).

> A better example might be doing things like changing the hostname,
> without being root, or start/stop a container/vm.

That's possible with policy-kit, tho I still think configuration
through XML is overly complex. A much simpler format could do, plus
make it actually human-readable.

> Sure, you can also do some of this using sudo, but sudo isn't actually
> a great tool for this as it is oriented around command line syntax,
> and not functional privileges.  The whole point of something like
> dbus/policykit is that you define what you want somebody to be able to
> do, not what commands they can type in order to try to do it.

Using sudoers configuration is a huge security pita if you don't
exactly know what you do configure. Plus, it is quite cumbersome when
it comes to only parsing command lines for decision. Especially on a
server, I do not really feel comfortable with that.

> dbus support for these sorts of administrative functions is still
> somewhat limited, and I suspect it will remain so until it is
> completely merged into the kernel (or rather, bus1 is).

I think it's rather missing some good frontend utilities (GUI and CLI).
Especially combined with policy-kit.

> It is also
> somewhat new for these sorts of things.  Previously it was more
> focused on desktop-like functionality, such as loading icc color
> profiles (apparently one of things you never will need).

Well, I think the "d" actually comes from "desktop". But with systemd
deployments, it also provides function for servers and their
management. I think, a lot can still be explored here. It's actually
useful. Tho, I'd also prefer a native kernel implementation with dbus
only sitting on top of it as a compatibility layer until all DEs
adapted it.

> Ultimately though the concept is a pretty sound one.  There are lots
> of things done in userspace where you'd want the same kind of
> granularity that posix capabilities offer in kernel space, and
> policykit is a way to eventually manage these.  UID=0 vs UID!=0 was
> once nice upon a time, but it isn't great for security, and the
> previous ways of addressing that tended to be lacking in various ways.

Well, let's wait for the argument "but this is not the unix way". ;-)


-- 
Regards,
Kai

Replies to list-only preferred.