The kdbuswreck

Posted Apr 22, 2015 21:24 UTC (Wed) by mezcalero (subscriber, #45103)
Parent article: The kdbuswreck

Jon, there are a number of errors in this text:

- "... the requested action will only be carried out if the requester has CAP_SYS_TIME, CAP_NET_ADMIN, or CAP_SYS_BOOT, respectively." -- this is simply incorrect. Nobody suggested something this. Having these caps should be *sufficient* to trigger the operations, but not *mandatory*. That's quite a difference.

- "... starting with the fact that capabilities are meant to be interpreted by the kernel, not by user space" -- that's hardly a "fact", that's merely an opinion.

- The part about "... Lennart Poettering doesn't see this limitation as a problem because user namespaces are not (yet) heavily used..." is pretty bogus, I never said that. Yes, I don't see that as limitation, but certainly not because userns weren't used, but simply because it is simply the right thing that processes of a different user namespace should not have rights in any other.

- "... feel that a process should explicitly indicate that it intends to perform an action requiring a specific capability before any such information should be sent..." -- this in fact has been implemented already after the first review round of the patches. And this has been mentioned in the various threads many times. Attaching creds is opt-in from both sides: the sender and the receiver of a message. Only if *both* sides allow/want the data it is actually attached.

- "Lennart .., is not thrilled with the suggestion that kdbus should support a user-space privilege mechanism" makes no sense. I never said anything like that, and systemd already supports a userspace authorization framework just fine, and uses it for most of its bus calls. That's what PolicyKit is.

Also, I don't think calling kdbus a "wreck" is appropriate at all.

The kdbuswreck

Posted Apr 22, 2015 21:46 UTC (Wed) by corbet (editor, #1) [Link] (17 responses)

Sigh. This always seems so hard.

"... the requested action will only be carried out if the requester has CAP_SYS_TIME, CAP_NET_ADMIN, or CAP_SYS_BOOT, respectively." -- this is simply incorrect. Nobody suggested something this. Having these caps should be *sufficient* to trigger the operations, but not *mandatory*. That's quite a difference.

Well, then, I'm genuinely confused. If you don't need the capability, why bother checking for it? If you're saying you're doing some other check (user running on the desktop, say), well, I didn't quite catch that. But I said "if", not "iff", so I can claim to have gotten it right :)

"... starting with the fact that capabilities are meant to be interpreted by the kernel, not by user space" -- that's hardly a "fact", that's merely an opinion.

Fine, it's an opinion, could have been expressed better. Obviously not everybody feels that way.

The part about "... Lennart Poettering doesn't see this limitation as a problem because user namespaces are not (yet) heavily used..." is pretty bogus, I never said that

The message from you linked in the article starts with you saying "I have seen no use of userns for sandboxing normal daemons so far. I have seen tons of daemons using caps for such sandboxing." Obviously you think that should have been interpreted some other way?

"... feel that a process should explicitly indicate that it intends to perform an action requiring a specific capability before any such information should be sent..." -- this in fact has been implemented already after the first review round of the patches. And this has been mentioned in the various threads many times. Attaching creds is opt-in from both sides: the sender and the receiver of a message. Only if *both* sides allow/want the data it is actually attached.

As you know, the "optional" nature of this is currently not universally believed. See the message from Andy linked at the point you stopped quoting.

"Lennart .., is not thrilled with the suggestion that kdbus should support a user-space privilege mechanism" makes no sense. I never said anything like that

Well, I quoted what you said. In retrospect it would have been better if I'd said "implement a new" instead of "support". They were suggesting you make something new and independent of capabilities, you clearly didn't like that idea — not entirely unreasonably, IMO.

Also, I don't think calling kdbus a "wreck" is appropriate at all.

...and I never did that. The title refers to the discussion, not the technology. If you think I see kdbus that way maybe you should reread what I've written, I don't think it was that unclear.

If you think the article was an unfair description of the disagreement I am genuinely sorry. I put a lot of time into trying to let all points of view shine through — it was not easy! And honestly, I don't think think it was that far off...

The kdbuswreck

Posted Apr 22, 2015 22:12 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (15 responses)

Reply to your first reply:

"Well, then, I'm genuinely confused. If you don't need the capability, why bother checking for it? If you're saying you're doing some other check (user running on the desktop, say), well, I didn't quite catch that. But I said "if", not "iff", so I can claim to have gotten it right :) "

Well, there are multiple ways how things can be authorized. Here's an example: logind will allow you to kill all processes belonging to a specific user session either if you have CAP_SYS_KILL, or if your user id matches the session's user. Neither of these security checks is mandatory individually, but having one of them is sufficient. That's the exact same way the kernel makes it's permission checks on CAP_SYS_KILL. This isn't an algorithm we invented, that's *HOW THESE THINGS WORK*!

And no, you can *not* claim you got this right, you did not. You wrote "only".

Reply to your third reply:

"The message from you linked in the article starts with you saying "I have seen no use of userns for sandboxing normal daemons so far. I have seen tons of daemons using caps for such sandboxing." Obviously you think that should have been interpreted some other way?

The issue I have is that you connected "Lennart Poettering doesn't see this limitation as a problem" and "user namespaces are not (yet) heavily used" with that little word "because". I said both of these things, but I never said that one was because of the other. That's something you incorrectly made up.

Reply to your fourth reply:

"As you know, the "optional" nature of this is currently not universally believed. See the message from Andy linked at the point you stopped quoting."

Oh well, if you don't believe what the kdbus folks say, how about actually *checking* the kdbus code? It's all open, for review. Also why would you assume that the kdbus developers are dishonest about this?

Reply to your fifth reply:

"Well, I quoted what you said. In retrospect it would have been better if I'd said "implement a new" instead of "support". They were suggesting you make something new and independent of capabilities, you clearly didn't like that idea — not entirely unreasonably, IMO."

There are two things you changed from what I said. In the mail you linked I said "...comprehensive new access control systems that can be used for in-kernel and in-userspace subsystems". First as you noticed by now, I said "new". Secondly, I said "comprehensive ... access control system ... for in-kernel and in-userspace subsystems", the emphasis being on *both* in-kernel and in-userspace here: caps can be that. PK cannot, it is userspace-only, and will never make sense in the kernel and it shouldn't have to.

Reply to your sixth reply:

You called this "kdbuswreck", not "kdbus discussion wreck" or similar. You know exactly how this works: people read the title and skip over the text, and "kdbus" and "wreck" is all that'll be stuck.

Anyway, please be more careful next time.

The kdbuswreck

Posted Apr 22, 2015 22:24 UTC (Wed) by corbet (editor, #1) [Link] (5 responses)

Oh well, if you don't believe what the kdbus folks say, how about actually *checking* the kdbus code? It's all open, for review. Also why would you assume that the kdbus developers are dishonest about this?

Oh come on, now you are just looking for trouble. Who said anything about dishonesty?

From Andy:

But I don't believe that for a second. AFAICS sd-bus (maybe the primary implementation) will always set that flag if for no other reason than that it *doesn't know* when the client is trying to assert a capability. So we'd be giving users a gun which is, in practice, only ever pointed at the users' feet.

He's not calling anybody dishonest either. He's saying the optionality at one level of the code is unlikely to make it through to real-world use. I believe you knew this.

With regard to the title...perhaps it was a bad choice, but "buswreck" (or "trainwreck") is a fairly common English term for an unfortunate situation. I still believe that you have to stretch pretty hard to say that "The kdbuswreck" (note "the") somehow refers to the code. And I'm somewhat amused by your statement that people read only my titles and not the actual text...

The kdbuswreck

Posted Apr 22, 2015 22:31 UTC (Wed) by branden (guest, #7029) [Link] (2 responses)

Next time, dear editor, just call it a clusterf*ck. :-|

The kdbuswreck

Posted Apr 23, 2015 4:21 UTC (Thu) by bronson (subscriber, #4806) [Link] (1 responses)

"The kdbust" has a more hopeless ring to it. :)

The kdbuswreck

Posted Apr 24, 2015 13:24 UTC (Fri) by ncm (guest, #165) [Link]

It would most precisely be called a "dust-up".

The kdbuswreck

Posted Apr 22, 2015 22:56 UTC (Wed) by mezcalero (subscriber, #45103) [Link]

To state this clearly: sd-bus allows overriding of both creds mask. By default though the receiving mask sets uid/pid/selinux label/caps, since that what is necessary for basic authentication. The sending mask allows all bits. If you choose to deviate from this, you can freely set other masks, note though that if you suppress the creds necessary for authorization this has the effect that all services that want to authorize will deny access to you, but I figure that's hardly surprising.

The kdbuswreck

Posted Apr 23, 2015 8:22 UTC (Thu) by edomaur (subscriber, #14520) [Link]

Well, I agree with Lennart, before reading the article, I assumed that it was, in fact, about the codebase.

The kdbuswreck

Posted Apr 22, 2015 22:37 UTC (Wed) by corbet (editor, #1) [Link] (8 responses)

Just for the record, I have made a few tweaks to the article in response to these complaints.

The kdbuswreck

Posted Apr 22, 2015 22:51 UTC (Wed) by mezcalero (subscriber, #45103) [Link]

Thank you very much, much appreciated!

The kdbuswreck

Posted Apr 23, 2015 1:57 UTC (Thu) by JdGordy (subscriber, #70103) [Link] (2 responses)

Reading the article after the corrections, I had no way of knowing if those strikethrough's were actual corrections or sarcastic jabs. You probably want to make it clear at the start (of better yet, just remove the corrected bits?)

Corrections

Posted Apr 23, 2015 2:03 UTC (Thu) by corbet (editor, #1) [Link] (1 responses)

Our policy is to not make silent changes to published articles for anything other than trivial typo fixes; an article shouldn't quietly mutate after it has been put out there. So the old stuff remains, even though I'd be happy to see it go. I did stick in a note up front noting that corrections have been made, though.

Corrections

Posted Apr 25, 2015 16:13 UTC (Sat) by Trelane (subscriber, #56877) [Link]

I saw this and find it greatly refreshing. This sort of transparency ought to be more prevalent in the fourth and fifth estates.

Your policy is fantastic. Thank you for it.

The kdbuswreck

Posted Apr 23, 2015 8:06 UTC (Thu) by speedster1 (guest, #8143) [Link] (3 responses)

IMO this was another excellent article on a complicated topic, and the fact that certain details could be improved by someone intimately involved with the effort being discussed does not imply otherwise.

LWN rocks!

Posted Apr 23, 2015 9:22 UTC (Thu) by rvfh (guest, #31018) [Link] (2 responses)

Isn't this the only place where we can actually talk to the editor and have explanations and even corrections made?

I have read so much bullsh*t on 'respected' newspaper sites where even commenting is useless because so many people need to send stupid comments without thinking for just one second, that seeing Jon listening, explaining and even fixing his already excellent article is like a breath of fresh air.

I really like LWN.

LWN rocks!

Posted Apr 23, 2015 20:40 UTC (Thu) by a9db0 (subscriber, #2181) [Link] (1 responses)

I second this.

Thank you, Jon, first for continuing to address thorny issues and make sense of them, and second for being responsive to your readers.

Dave

LWN rocks!

Posted Apr 25, 2015 12:19 UTC (Sat) by louai (guest, #58033) [Link]

LWN is awesome. Thank you very much indeed for all the hard work!

For what it's worth, I think the article is balanced and very informative.

Louai

The kdbuswreck

Posted Apr 22, 2015 22:13 UTC (Wed) by jjmarin (subscriber, #53201) [Link]

I agree that "The kdbuswreck" is a misleading title, IMHO, I think the title should be more precise to convey the general meaning of the article, maybe something like "The kdbus debate wreck"... anyway, I'm sure there must be a much better suggestion for the title :-)