The kdbuswreck

Posted Apr 23, 2015 0:00 UTC (Thu) by ncm (guest, #165)
In reply to: The kdbuswreck by fandingo
Parent article: The kdbuswreck

They can't be scrapped, and can't be fixed. To me that means "stay away. Far away".

The kdbuswreck

Posted Apr 23, 2015 5:14 UTC (Thu) by hrogge (guest, #100012) [Link] (7 responses)

The problem is that I have yet to see anyone suggesting how a solution to the problem could look like.

Is there any good concept how the API of a "permission" system to replace capabilities could look like? Maybe even one that could be initialized through the capabilities API so there is a graceful fallback?

Saying "capabilities is bad, don't us them" is not really helpful without a good suggestion how to replace them.

The kdbuswreck

Posted Apr 23, 2015 11:31 UTC (Thu) by HIGHGuY (subscriber, #62277) [Link]

Could capabilites be translated to BPF filters on syscalls? Probably inheritance of these filters may be missing...

The kdbuswreck

Posted Apr 23, 2015 12:34 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

From what I've seen, Capsicum[1] appears to be something that would be much better.

[1]http://www.cl.cam.ac.uk/research/security/capsicum/

The kdbuswreck

Posted Apr 23, 2015 13:33 UTC (Thu) by justincormack (subscriber, #70439) [Link]

Yes Capsicum is along the right lines, you could send file descriptors embodying the capabilities. I don't think it has enough capabilities for some of the things being discussed, but sending file descriptors is the right way...

The kdbuswreck

Posted Apr 23, 2015 23:38 UTC (Thu) by neilbrown (subscriber, #359) [Link]

> The problem is that I have yet to see anyone suggesting how a solution to the problem could look like.

What is "the problem" - specifically? Once you have that clearly stated, the solution probably isn't far away (and it probably involves file descriptors - most good solutions do).

> Maybe even one that could be initialized through the capabilities API so there is a graceful fallback?

I think the capabilities API could be part of the problem, not part of the solution.

Consider Superman. He can jump without flying, can look without burning holes, can listen without hearing every mouse's footstep. His super-powers only take effect when he wants them too.
If "capabilities" don't need to be explicitly activated every time they are used, then they are really just "defaults". And default super-powers can cause a mess.

The kdbuswreck

Posted Apr 30, 2015 10:44 UTC (Thu) by metux-its (guest, #102293) [Link] (2 responses)

At this point, I'd rather raise the question, what's _actual_ problem to solve ? Some practical real-world usecases ?

Things like allowing certain (otherwise unprivileged) processes or users to trigger a shutdown (via the init system, of course) can be easily done with traditional unix mechanisms. No need for caps, nor dbus.

The kdbuswreck

Posted Apr 30, 2015 14:29 UTC (Thu) by ksandstr (guest, #60862) [Link] (1 responses)

Simply put, the idea with capabilities was that a process that has root privileges shouldn't be able to do all that root can, but instead just a narrow slice thereof. This restricts setuid binaries to privileges required for their stated purpose, and nothing else. The desired upshot is a limitation of the damage from successful compromise of setuid binaries and (restrictable) processes otherwise running as root.

It likely didn't help that academia at the time was still mildly abuzz with capability-based this and capability-based that, and that the relevant research papers would read like exercises in ontological wank -- for example, calling a process' knowledge of a path name a "capability" as it makes the process capable of accessing that entry (or discovering that it cannot). While that way of looking at things does account for things like forking (which implicitly copies data such as pathnames), it has precious little to do with the split-root capability mechanism of Linux besides having a word in common and an application in the field of access control.

Historically, then, a "capability" can mean basically everything, which makes it a good word for marketing towards the uncritical and unwary much like "the cloud". [Imagine a snarky remark wrt implied corporate braindamage in systemd here.]

The kdbuswreck

Posted Apr 30, 2015 18:25 UTC (Thu) by ms_43 (subscriber, #99293) [Link]

You should not confuse POSIX.1e capabilities, as implemented by Linux, with the capabilities described in security research literature for many years, which are quite precisely defined (and I really wonder why the POSIX committee used that term).

Linux also has *those* capabilities (in a very limited form), they are just called "file descriptors".

The closest you're going to get to a capability-based security model with a traditional UNIX-like kernel is Capsicum.

http://lwn.net/Articles/482858/

(Insert standard rant about kids these days thinking that "operating system" is a synonym for UNIX)