[Trying again due to HTML mail goof. Trimming and responding better, too.] On Fri, Apr 3, 2015 at 4:51 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > Hi > > On Tue, Mar 31, 2015 at 8:29 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Tue, Mar 31, 2015 at 8:10 AM, Tom Gundersen <teg@xxxxxxx> wrote: >>> On Tue, Mar 31, 2015 at 3:58 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>>> >>>> IOW you're taking something that you dislike aspects of and shoving >>>> most of it in the kernel. That guarantees us an API in the kernel >>>> that even the creators don't really like. This is, IMO, very >>>> unfortunate. >>> >>> This is a misrepresentation of what David wrote. We do want this API >>> regardless of dbus1 compatibility, but compatibility is by itself a >>> sufficient motivation. A further motivation is reliable introspection, >>> since this meta-data allows listing current peers on the bus and >>> showing their identities. That's hugely useful to make the bus >>> transparent to admins. >> >> I've heard the following use cases for per-connection metadata: >> >> - Authenticating to dbus1 services. > > Not necessarily authentication, but we need to support the legacy API, > for whatever reason it was used by old applications. But.. > >> - Identifying connected users for admin diagnostics. >> >> I've heard the following use cases for per-message metadata: >> >> - Logging. >> >> - Authenticating to kdbus services that want this style of authentication. > > ..please note that authentication on DBus has always been done with > per-message metadata (see polkit history). However, this had to be > reverted some years ago as it is racy (it used /proc for that, which > can be exploited by exec'ing setuid binaries). However, the > per-message metadata authentication worked very well for _years_ > (minus the race..), so this is already a well-established scheme. With > kdbus we can finally implement this in a race-free manner. > > [...] >> This is simply not okay for a modern interface, and in my opinion the >> kernel should not carry code to support new APIs with weakly defined >> security semantics. It's important that one be able to tell what the >> security implications of one's code is without cross-referencing with >> the implementation of the server's you're interacting with. > > Again, I disagree. Our concepts are established and used on UDS and > DBus for decades. SO_PASSCRED does not justify anything in my book. It was a mistake and it remains a minor disaster. Please don't use it as justification for something being a good idea. Similarly, the fact that the *receiver* chooses which of SO_PASSCRED and SO_PEERCRED to use is awful. > > Yes, we provide two ways to retrieve metadata, but the kernel offers > several more paths to gather that information. Just because those APIs > are available does not mean they should be used for authentication. We > mandate per-message metadata. If applications use per-connection > metadata, /proc, netlink, or random data, they're doing it wrong. ISTM kdbus is trying to add three more interfaces, at least two of which are also doing it wrong. (Which two is debatable.) > > Furthermore, dbus provides pretty complete and straightforward > libraries which hide that from you. If you use glib, qt or sd-bus, you > don't even need to deal with all that. Libraries can't hide the issue of whether: init_my_favorite_library(); connect_to_thingy(); setresuid(nobody); is secure. It is either secure, insecure, or ambiguous. Unfortunately, kdbus as currently proposed is aiming for ambiguous. > >> To top that off, the kdbus policy mechanism has truly bizarre effects >> with respect to services that have unique ids and well-known names. >> That, too, is apparently for compatibility. >> >> This all feels to me like a total of about four people are going to >> understand the tangle that is kdbus security, and that's bad. I think >> that the kernel should insist that new security-critical mechanisms >> make sense and be hard to misuse. The current design of kdbus, in >> contrast, feel like it will be very hard to use correctly. > > Native kdbus clients are authenticated with their credentials at time > of method call. Legacy clients will always have their credentials at > time of connect in effect. No fallbacks, no choices. It's a simple > question whether it's a legacy client or not. > Sounds simple to me. I had the distinct impression that the kdbus-client-to-dbus1-server proxy used kdbus clients' connection metadata. I could be wrong here. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
