LWN: Comments on "Poettering: The new sd-bus API of systemd"

nothing learned

thestinger — Sat, 04 Jul 2015 14:14:07 +0000

> One solution is capability-based security, which doesn't use names or ACLs at all. I'm personally rather partial to it. It's simple and it works. Bizarrely, Android's Binder is capability-based, but the stuff built on top of it mostly throws it away and uses GIDs.

Android doesn't use secondary GIDs in the general case, only for a small subset of the built-in permissions. Those permissions are mapped to GIDs for POSIX file permissions or SELinux roles and a few are enforced by hard-wiring GIDs into the kernel. It's usually enough that each application runs with a unique uid/gid pair so secondary groups or the capability model aren't necessary. There's just a look-up to see if that application was statically granted the permission.

The use cases are usually too trivial to merit usage of tokens but they do use them for a few very dynamic things like the window manager handles.

Poettering: The new sd-bus API of systemd

thestinger — Thu, 02 Jul 2015 23:21:37 +0000

> Okay, she's chronically ill, which seriously doesn't help matters, but why change that which works perfectly okay!?!?!?

Not having her identity stolen due to unpatched security holes would be one reason. Using old software is quite distinct from using software that's unsupported and known to be insecure.

Poettering: The new sd-bus API of systemd

rahulsundaram — Tue, 30 Jun 2015 15:44:03 +0000

>A clean, low-dependency, performant, portable DBus library - be great if someone developed that. :)

Nothing is preventing someone from porting sd-bus if they desire that. See: OpenSSH.

Poettering: The new sd-bus API of systemd

paulj — Tue, 30 Jun 2015 15:35:46 +0000

libdbus has a sprawling API. GDBus has, I gather, performance issues and is of course tied to GLib, which not everyone wants.

A low-dependency, performant, portable DBus library with a clean API would definitely help some users - it'd fill a niche. From a look at Lennart's blog, and the header files, it looks like sd-bus fits the bill on API at least. Presumably it also performs well. Sadly, it doesn't seem like it will ever tick the other boxes, given what Lennart has stated here.

A clean, low-dependency, performant, portable DBus library - be great if someone developed that. :)

Poettering: The new sd-bus API of systemd

rahulsundaram — Tue, 30 Jun 2015 13:35:27 +0000

The advantage of sd-bus is that it can work with either d-bus on the userspace or kdbus. If you don't care about that, GDBus or libdbus might be just fine. Why would you want to bundle sd-bus?

Poettering: The new sd-bus API of systemd

jtaylor — Tue, 30 Jun 2015 11:34:12 +0000

I think point is more that this useful library is tighly coupled to systemd sources so it cannot easily be extracted to a standalone library (as stated by Lennart in http://lwn.net/Articles/649378/)
If it were standalone you could easier just bundle it with your application and not care about what CentOS/RHEL or any other distribution ships.

Poettering: The new sd-bus API of systemd

atai — Fri, 26 Jun 2015 23:41:32 +0000

How much are Red Hat or GNU (gcc) developers responsible for that? Maybe C++ evolves too fast?

nothing learned

Wol — Tue, 23 Jun 2015 14:25:48 +0000

Ah. Unclear language.

Pr1mos didn't mix User and Group rights - it stopped at the first match ...

You're assuming that a group got picked at "random", it didn't, it added all your group rights together.

So if it was

foo:lur
bar:larw

If you were in foo and bar you'd get alurw.

And if I only wanted you to have lur, I'd have to specify you by user id, at which point it would ignore any groups.

Cheers,
Wol

nothing learned

luto — Mon, 22 Jun 2015 20:27:07 +0000

> But, in my approach, how does adding a user to a group REDUCE permissions? If he's already got group permissions, adding a new group merely ADDS MORE permissions.

In your approach, imagine this ACL:

g:foo:x
g:bar:rwx

If you are in group bar, then you get rwx. If you add yourself to group foo, then you lose r and w.

nothing learned

Wol — Mon, 22 Jun 2015 20:16:00 +0000

It's also making the error of assuming that privileged clients exist - surely any sane security model would "assume and enforce" that there is no such thing as a privileged client ... :-)

Again, going back to a system I used many moons ago - Pr1mos - the only privilege that you could not take away from the super-user was the right to set privileges. I regularly used to lock the superuser out of the live disks, so I could test something dangerous secure in the knowledge that - OS bugs aside - if something went wrong it could only affect my test data.

Cheers,
Wol

nothing learned

Wol — Mon, 22 Jun 2015 20:07:58 +0000

But, in my approach, how does adding a user to a group REDUCE permissions? If he's already got group permissions, adding a new group merely ADDS MORE permissions.

If he hasn't got group permissions, then adding him to a group may change his security model from "default" to "group". Which will change his permissions (and could actually reduce them ...)

But if he's already got explicit user permissions, then nothing you do to his groups will change the permissions he's got.

Cheers,
Wol

Poettering: The new sd-bus API of systemd

jgg — Mon, 22 Jun 2015 17:54:57 +0000

> It is possible to make the same sentences with the gcc: if you use a feature of the gcc-5.1, your code simply doesn't work in old system.

No, not even remotely true. I have code here which hard requires C++11, meaning G++ 4.8 *minimum* to compile it, but I routinely build Centos6 RPMs. Yes, I have to use an add-on compiler, and RH has done a great job providing devtoolset to do exactly that.

If we ever get to the point where using C++17 features make sense, then the build process will likely shift to using devtoolset + super-new-clang on CentOS6. The end result is the same, the binary works transparently on CentOS6 installs, and the person using the RPM has no idea that it was built with a modern compiler.

Poettering: The new sd-bus API of systemd

jgg — Mon, 22 Jun 2015 17:46:19 +0000

> I'd say, you don't. You focus on getting it onto centos 8 or 9.

No, that is nonsense. People running older CentOS's want the kernel/core stability and hardware support. They are perfectly happy with *adding* new things to the install, as long as the core stuff isn't changed. It is actually really common for CentOS users to want the base OS and the 'latest version' of the critical app the box is supposed to run.

Something core like KDE is not a good example, think more like a self contained leaf app like Google Chrome, or gcc.

As a developer, I have no interest in targeting those old versions, except that is where the users are. So development is done on some leading distro with new everything, and the CentOS builds are an annoying backport exercise. This way the app is ready to take advantage of CentOS 8 features/etc, and is easier to write. Using sd-bus would make the app quite a bit easier to write..

How to backport systemd stuff is the annoying bit. Even the .service file is proving difficult, I just learned that CentOS 7 doesn't support KillMode=mixed .. sigh.

Poettering: The new sd-bus API of systemd

rahulsundaram — Mon, 22 Jun 2015 14:19:01 +0000

"You got it backwards. More often than not software is being written in the current distro version, that will be the just obsolete one when the software hits the road."

I have difficulty parsing that. To give a specific example, there are tons of features currently funded by Red Hat including say Wayland or any number of Linux kernel features and only a few of them will be backported to EL7 or EL6 but most of them will go into EL8 or a future update. EL6 or EL7 will not be obsolete for years after EL8 has been released because you pay for a subscription and not for any single release and customers upgrade when they want to.

Poettering: The new sd-bus API of systemd

dgm — Mon, 22 Jun 2015 07:57:29 +0000

> They are often funding it for a future distro release and not the current one.

You got it backwards. More often than not software is being written in the current distro version, that will be the just obsolete one when the software hits the road. Somethimes it is even an older version (like I'm doing right now), because the OS version supported by the hardware vendor is not the most recent (and will NEVER, EVER be the next one).

Poettering: The new sd-bus API of systemd

khim — Sun, 21 Jun 2015 23:40:16 +0000

Apart the libgcc.*so dependencies, the point is that if someone has a Centos 7, he doesn't want to change anything (gcc, libs or anything else).

It does not mean anything like that. If you use Centos 7 (or even Centos 6!) you still may want to use GCC 4.9 or even 5.x (for it's C++11/C++14 features). Thankfully RHEL (and CentOS) are OSes for “normal” people thus GCC 4.9 is fully supported (yes, even on RHEL6/CentOS6 with deployment target being RHEL6/CentOS6), GCC5 is not yet supported but will, hopefully, be supported later. I guess RHEL could provide SD-Bus in devtoolset's libsystemd, too.

And people wonder why THE GNU/Linux for enterprise packages is RHEL and RHEL only! Because, well, it's the only distribution out there which provides natural (natural for users of all other OSes) capabilities to developers! Other distros don't even try to do that!

it's nowhere near finished

jengelh — Sun, 21 Jun 2015 22:55:09 +0000

"Since sd-bus does not read mail (yet), perhaps there is still some hope for it for a while" ;-)

nothing learned

luto — Sun, 21 Jun 2015 21:39:11 +0000

Let me say it better: a well designed permission system (the think in the kernel or low-level libraries, not the thing in your Apache config) should be easy to understand, easy to reason about, and flexible enough to implement strong security policies. If you want to give a whole bunch of users, but not Jo, access to something, you should probably be able to do that. This doesn't mean it's a good idea to bake a particular user matching algorithm into the kernel that specifically targets your use case.

nothing learned

luto — Sun, 21 Jun 2015 21:37:14 +0000

> A system service that cannot determine if the client talking to it is privileged would be useless, hence from day one this has been one of the main design goals with D-Bus.

As an axiom about security models, this one isn't really true. In a capability-based model, there is nothing to determine: if you're calling methods on some system object provided by a system service, then you have permission, full stop.

nothing learned

luto — Sun, 21 Jun 2015 20:02:36 +0000

I think that approach is the worst. Adding a user to a group should never reduce permissions -- that way lies madness and errors. Even POSIX gets this wrong.

Reducing permissions for specific users is bad, too. If everyone except Jo can read some file, can Jo's sandboxes web app access the file? What about the guest account that Jo uses?

Poettering: The new sd-bus API of systemd

judas_iscariote — Sun, 21 Jun 2015 19:21:39 +0000

You are missing a very important detail.. people that buy enterprise distributions do not want changes or new components introduced later..neither at the software nor hardware level (that's why they are only sold to be used on pre-certified hardware with a particular package selection under official support)

Companies pay developers for their time and knowledge to keep those old components working for a very long time and the develop new solutions for future releases.

nothing learned

Wol — Sun, 21 Jun 2015 19:14:31 +0000

And even ACLs have different, thoroughly confusing, permission models. I've never used Linux ACLs, but ...

imho Windows does it totally wrong, it ADDS group- and id-based permissions.

The system I'm used to (and I admit I may think it's right because it was the first one I learned, but it does feel so much simpler) gave you rights, but STOPPED AT THE FIRST MATCH. So it searched user permissions, and if it found you, you got the rights allocated to your user id. If it didn't find you, it then searched for your group rights and gave them to you. If it didn't find any of those, it then gave you the default "anyone else" rights.

So if I put "Jo Bloggs : no rights" on my files, then Jo Bloggs couldn't even list them to find they were there! Even if he was a member of the admin group, and admin had all rights, the fact that it said "Jo Bloggs : no rights" overrode any and all group rights. Simple, easy to comprehend, and minimal room for error.

Cheers,
Wol

nothing learned

mezcalero — Sun, 21 Jun 2015 18:29:11 +0000

Both dbus1 and kdbus have provisions for identifying who you talk to and they are absolutely essential for its mode of operation. A system service that cannot determine if the client talking to it is privileged would be useless, hence from day one this has been one of the main design goals with D-Bus. In fact the whole PolicyKit framework is built around the D-Bus credential logic, using the basic primitives D-Bus exposes to build a security policy database.

In dbus1 the dbus-daemon (which is a system daemon) guarantees you unfakable security credentials, and it does so based on the kernels SO_PEERCRED logic. On kdbus, it's the kernel itself that passes unfakable security credentials around from the caller to the callee.

For kdbus we spent quite some time to ensure that neither side has to trust the other in any way. For example the memfd sealing logic was created for this very reason (and this part is even already in the upstream kernel).

Hence, I don't see an failure here. It's one of the strong points of D-Bus, and has been since day 1.

Lennart

nothing learned

luto — Sun, 21 Jun 2015 17:00:11 +0000

I assume that ncm means that we should be using a security model that is easy to understand, scales all the way from multi-user systems to fine-grained sandboxes and is not dependent on the admin or distro defining a long menu of options to use when authenticating based on your identity. This model is already broken in most deployments. For example:

One of the recent "XARA" attacks against iOS is based on iOS's assumption that, if you are some random framework, you should have access to that framework's files. What they missed is that two vendors might have different things claiming to be the same framework.
Another of the XARA attacks abuses a broken Keychain ACL model in which entries are globally named but have ACLs based on identity. Why are we using global names to identify objects across security boundaries in the first place?
Even on Windows NT or XP, ActiveX was fundamentally insecure because an ActiveX applet had the same identity as the person in front of the keyboard.
Linux, and POSIX in general, mostly identifies things by UID and maybe by LSM label or some other newfangled name. How does your lolcats browser tab, or maybe the ad on the top of your lolcats browser tab, fit in to that model?

One solution is capability-based security, which doesn't use names or ACLs at all. I'm personally rather partial to it. It's simple and it works. Bizarrely, Android's Binder is capability-based, but the stuff built on top of it mostly throws it away and uses GIDs. D-Bus, however, can only pass object identifiers by name and this cannot cleanly handle delegation or principals who are authorized by anything other than an ACL.

In summary, sure, D-Bus has authentication based on who you are, but by the time you've asked a method's caller who it is, you've probably already lost. You really want to be asking what fine-grained object-specific rights it has, and D-Bus can't do that.

Poettering: The new sd-bus API of systemd

ms_43 — Sun, 21 Jun 2015 12:57:43 +0000

Well, you may be able to do that for C perhaps; if you try with C++ you will find that every new libstdc++ release adds loads of new symbols that will be missing from your deployment platform if it is older than your GCC.

Then you bundle libstdc++.so with your app and notice that C++ is becoming increasingly popular in system libraries: Mesa OpenGL drivers such as radeonsi_dri.so require libstdc++.so. So if you bundle libstdc++.so, will your application fail to load that driver if you run it on a newer system that has a OpenGL driver that requires symbols from libstdc++.so that your bundled one doesn't have?

At this point you realize what a horrible idea the ELF global symbol namespace is. Windows doesn't suffer from that problem (but it has other problems to compensate).

There is now a clever solution to that problem called the Red Hat Developer Toolset, which contains a GCC that links against the build system's libstdc++, and in addition to that it also statically links an archive with all the libstdc++ symbols that are missing from the build system's libstdc++.so.

it's nowhere near finished

cortana — Sun, 21 Jun 2015 10:17:30 +0000

Please try to increase the signal:noise ratio when you comment, rather than the reverse.

it's nowhere near finished

cas — Sun, 21 Jun 2015 01:43:23 +0000

it doesn't have a network file system built in yet OR a tftp server or coffee-pot temperature monitor, and they haven't even started work on the API for the poetterfish super-duper encryption algorithm.

Poettering: The new sd-bus API of systemd

zblaxell — Sun, 21 Jun 2015 01:41:35 +0000

> > If I design an app around sd-bus (which I actually want to do), then how on earth do I get it onto Centos 7?

> You don't.

I, for one, agree with that. There's no point wasting time developing on top of something while there's still a risk that upstream will just disappear when they get bored with it.

An early adopter's role is to forge new technologies in the fires of early deployment, hardening them to a state where everyone can install them and forget they're there. Nobody else has time for that, so they won't be using sd-bus (or, by the sound of it, your app) any time soon. As a developer, you must decide where your target audience is on that spectrum, and plan accordingly.

Today, use whatever has already survived at least as long as you'd like your app to; otherwise, you'll end up reimplementing your apps over and over again because they'll be built on top of sand.

Poettering: The new sd-bus API of systemd

zblaxell — Sun, 21 Jun 2015 00:58:04 +0000

> If you write an application which depends by a new library/software, simply this doesn't work in old system.

If the app requires a new kernel feature that may be the case. This is one of the reasons why it's so (intentionally) hard to add new kernel features.

If the app just needs a library, it can include a copy of the library in itself, or the developer can provide a backport to install as a separate package. This is mostly possible because the kernel is managed so conservatively (relatively speaking...I can hear the BSD people chuckling in the background).

It's when the app requires replacing existing servers on the system (some entity that exclusively occupies a name in a namespace, like your SMTP TCP port, or the dbus address of services built into systemd) that the problems pop up.

Poettering: The new sd-bus API of systemd

hp — Sun, 21 Jun 2015 00:36:05 +0000

the profile in that thread on linux-kernel was mostly gdbus, but the dbus daemon doesn't use gdbus, it uses libdbus.

Not that libdbus is super fast or anything. But read the rest of the thread, which includes a suggestion to try sd-dbus instead.

Poettering: The new sd-bus API of systemd

rahulsundaram — Sat, 20 Jun 2015 23:14:41 +0000

They are often funding it for a future distro release and not the current one. Remember, the whole point of enterprise distros is to provide stability and they can't realistically do that while providing the very latest features all the time. You may be able to influence which features gets backported however in some circumstances if you are a customer.

nothing learned

tialaramex — Sat, 20 Jun 2015 20:49:59 +0000

The design, about which you complain, seems to have taken this into account by providing for SASL-like authentication. Am I missing something? Is your complaint misdirected and you're actually not happy with the present implementation rather than the design? Or is there something more subtle that you just neglected to actually mention?

Poettering: The new sd-bus API of systemd

Wol — Sat, 20 Jun 2015 20:49:10 +0000

> Actually suits are the sane ones here, not techies.

A O **** L

Yes it's great that we have all these wonderful new technologies, but the *young* techies seem to think that anything old must be rubbish - in fact most things "shiny and new" are just re-inventing the wheel!

And, as we get older, we get left behind by change. Some people remain young, some people are born old, but most people find it harder and harder to learn new stuff as we age. If the new stuff is better, then great, but for MOST people, the most intuitive interface is what they learnt when they were young, and throwing out the old stuff just because it's old disenfranchises an awful lot of people.

My wife, for example, still uses XP. I haven't tried to transition her to anything newer because the effort of coping with change is too much. Okay, she's chronically ill, which seriously doesn't help matters, but why change that which works perfectly okay!?!?!?

Cheers,
Wol

Poettering: The new sd-bus API of systemd

edeloget — Sat, 20 Jun 2015 19:44:37 +0000

Regardless of the fact that companies who are using these enterprise distros often pay developers to work on new softwares for these distro?

nothing learned

ncm — Sat, 20 Jun 2015 18:42:03 +0000

How can we have deployed yet another IPC services model that assumes everybody and everything (with absolutely trivial exceptions) must trust one another implicitly, based on no more than who appears to be talking? The mind boggles.

We will all have to start over from scratch with yet another in just a few years. Pray that whoever initiates that one learns something, first, from all the failures that came before, including this one.

Poettering: The new sd-bus API of systemd

khim — Sat, 20 Jun 2015 17:56:40 +0000

Many techies know that, but sadly, fewer suits do...

Actually suits are the sane ones here, not techies. If you'll think about non-“computer science field” technologies then you'll find out that there are many changes happen each year, too. But it does not mean lathes and presses are replaced each year! It's not uncommon to see half-century old machines deployed alongside with “latest and greatest” ones: if they work adequately then what's the point of introducing pointless disruption in the process?

They expect that “computer science field” will play by similar rules—and it does! You could use Visual Studio 2015 to develop Windows XP compatible packages (and of course they could use most of technologies introduced in last 15 years). You could use latest Android SDK and write app which will use latest and greatest goodies on Android 5.1 yet will still run on Android 2.3 (and of course it could use many things introduced in last year, too).

“Suits” see that “computer science field” acts sanely and naturally assume GNU/Linux could act sanely, too. And it does, of course, one solution is to use as few things from distros as possible (e.g. here we are creating our own deployment system which is completely separate from underlying OS: it carries it's own versions of GLibC, libgcc and everything on top). It would have been great to see sane distro which will develop something else than CADT model but I doubt it'll happen any time soon.

Poettering: The new sd-bus API of systemd

dashesy — Sat, 20 Jun 2015 16:39:28 +0000

This is the best explanation I have seen, I only tried DBus for Bluetooth once and it never made sense to me so much I hated it immediately. I wish I knew about bash completion for busctl before! Finally Lennart is bringing some sense to desktop.

Poettering: The new sd-bus API of systemd

kreijack — Sat, 20 Jun 2015 14:48:54 +0000

> Gcc is a nearly unique exception, actually. You can relatively easily install a new gcc on an old system,
> build things, and even copy the result to systems that don't have the new gcc installed.

Apart the libgcc.*so dependencies, the point is that if someone has a Centos 7, he doesn't want to change anything (gcc, libs or anything else).
If you want the maximum stability, you should care to not use anything else than the standard packages. Centos 7 is stable if you use its compiler; if you use a different one (doesn't matter if the host is another system), you loose the stability guarantee.

To be clear, if you use a new compiler I suppose that you have the 95%/99% of probability that everything is ok. But if you use a CentOS 7, it is likely that you want more guarantees.

Poettering: The new sd-bus API of systemd

Lionel_Debroux — Sat, 20 Jun 2015 14:34:16 +0000

The software part of the computer science field is one of the fastest evolving domains of mankind knowledge and technology, and it's evolving faster and faster over time. In the CS field, a 5-7 year span is extremely long, except for niche markets. Not taking advantage of software technology published in the last 5 years - and there are so many such things - is severely holding oneself back. Many techies know that, but sadly, fewer suits do...

Most people should write software now, based on today's technology which is known to remain relevant and a safe bet for tomorrow (while keeping an eye on disruptive technology), and let there be at most 2-3 years lag between writing the software and getting it to the users. In any case, hopefully before their competitors, who may well have a better clue about modern technology, write and release said software as open source.

Poettering: The new sd-bus API of systemd

luto — Sat, 20 Jun 2015 14:24:08 +0000

Gcc is a nearly unique exception, actually. You can relatively easily install a new gcc on an old system, build things, and even copy the result to systems that don't have the new gcc installed.