The kdbuswreck [LWN.net]

The kdbuswreck

Posted Apr 24, 2015 23:39 UTC (Fri) by cesarb (subscriber, #6266)
In reply to: The kdbuswreck by kentonv
Parent article: The kdbuswreck

> This socket is never linked into the filesystem, but is created as a socketpair and then passed to the user's login process as, say, FD 3. In theory, the user would then even be able to decide which processes that they run should have access to this capability and which shouldn't, by deciding to pass the cap through or not.
> Of course, at this point we're talking about a very different world from the status quo. It's unlikely that we'll rewrite all our tools to work this way anytime soon.

As a Gedankenexperiment, here's a simple way to implement that without having to rewrite all our tools:

On the kernel, create a "capability table" next to the "fd table", with the exact same lifetime rules (so, for instance, CLONE_FILES also shares the "capability table"). Create two new flags for dup3(), DUPFD_FROM_CAP and DUPFD_TO_CAP, which mean that, respectively, the oldfd or the newfd parameter refer to the "capability table" instead of the "fd table". That's all that needs to be changed in the kernel.

The user, when they log in, receives the "account management" capability in some slot of the capability table, plus an environment variable telling it which slot has that "account management" capability. Unmodified programs will not touch either the "capability table" or the environment variable, so both will be inherited by every program in the user's session.

The "passwd" program, then, would look for that environment variable, get the slot number from it, and pass that slot number to dup3() with DUPFD_FROM_CAP, to copy the FD to the "fd table". It can then talk normally to the "account management" service on the other side of the socket.

to post comments

The kdbuswreck

Posted Apr 25, 2015 0:08 UTC (Sat) by kentonv (subscriber, #92073) [Link] (1 responses)

Hmm, I think the main thing I'm worried about is not that capability FDs will be indiscriminately closed by existing tools (e.g. ones that explicitly close all FDs above 2 before exec), but rather the opposite: that it will be too easy to inherit capabilities when you don't intend to. That gets back to "ambient authority". Really, the capability should only be passed on to processes that need it. This means that intermediate apps (e.g. shells) need good ways to explicitly control when to pass capability FDs without getting overly verbose. Today's shells are actually not that bad at this, but some further improvement would probably be desirable, and desktop environments are another matter.

I think putting capabilities in a separate table would actually be a step backwards, in that all the existing tools that work with FDs would not work with these. That means you couldn't manipulate them in bash, you couldn't pass them over unix domain sockets, etc.

The kdbuswreck

Posted Apr 25, 2015 0:52 UTC (Sat) by cesarb (subscriber, #6266) [Link]

> I think putting capabilities in a separate table would actually be a step backwards, in that all the existing tools that work with FDs would not work with these. That means you couldn't manipulate them in bash, you couldn't pass them over unix domain sockets, etc.

They are still FDs, just stashed away in a "shadow" table. They could be easily passed over unix domain sockets (dup3 to the normal table, send it over, and close the copy in the normal table).

I agree that hiding them makes them impossible to manipulate with unmodified tools like bash, but that's sort of the point of the thought experiment: a way to add capability FDs without interfering with anything which doesn't use them, thus allowing for gradual introduction of the feature. It's only a thought experiment, after all.

There's precedent for that sort of trickery: I recall seeing some discussion here on LWN about a way to allow libraries to open FDs without interfering with or being interfered by the application (IIRC, the proposal was to stash them as directly-allocated high-numbered FDs, instead of using the lowest available slot).