Capability-based security and confused deputy

[PeterX]

I've read Wikipedia about capabilty-based security, ACL, C-lists, confused deputy problem.
I wonder if with capabilities confused deputy really is impossible!?
It seems to me that still someone can fool a higher ring app/code to breach the security.

Greetings
Peter

[Korona]

Can you formulate a concrete problem that you see so that we can give a precise answer? All terms that you mention are kind of broad.

[PeterX]

Can you formulate a concrete problem that you see so that we can give a precise answer? All terms that you mention are kind of broad.

My question was general because I'm planning (and not yet coding) an exokernel. And I want to use ACLs for it. But I've read in two internet texts that ACLs are vulnerable because someone could trick an application with higher privilege to do something "bad". And capabilities are said to be the solution.
I hope this makes it more concrete.

Greetings
Peter

[nullplan]

Whenever you have levels of privilege and a way for someone to attain higher privilege temporarily, you will have the confused deputy problem. Using "capability based security" does not change that. In fact, the problem exists whenever an attacker can influence a program running with access the attacker does not have. For example, a TCP service running on my server already has access to things an attacker in the internet does not have, namely my CPU, RAM and disk. If an attacker can confuse the TCP service into running a shell on some port, we have exactly the confused deputy problem, and capabilities never came into it. The attacker does not exist as a user on my server and therefore cannot have capabilities.

TL;DR: Security is hard. There is no one-size-fits-all solution. Choose a model and run with it. Smarter people than you or I have banged their head against that particular wall and it just refuses to fall.

[bzt]

My question was general because I'm planning (and not yet coding) an exokernel. And I want to use ACLs for it. But I've read in two internet texts that ACLs are vulnerable because someone could trick an application with higher privilege to do something "bad". And capabilities are said to be the solution.
I hope this makes it more concrete.

I'm afraid not really. If we don't count the actual implementation, then capabilities can be seen as hardwired ACL of some sort. Which means yes, they can solve the issue in theory, but the most important question is, is this really an issue?

I mean an "application with higher privilege" can alter the ACL is really bad? In all systems that I know of there's a higher privilege level (uid 0, root on UNIX) that can change groups / ACLs / whatever. For the records, VMS solves this by introducing the concept of the control ACE, aka. the ACL list has its own owner, who is allowed to change (control) the list. Each ACL might have a different owner. But to be honest, VMS also has a BYPASS ACE, meaning if any of the ACLs has that ACE, no security checks will be done, so that process with BYPASS will be able to modify other ACLs unconditionally (effectively equivalent of running as uid 0).

L;DR: Security is hard. There is no one-size-fits-all solution. Choose a model and run with it. Smarter people than you or I have banged their head against that particular wall and it just refuses to fall.

Sadly, that's true!

Cheers,
bzt

[PeterX]

Whenever you have levels of privilege and a way for someone to attain higher privilege temporarily, you will have the confused deputy problem. Using "capability based security" does not change that. In fact, the problem exists whenever an attacker can influence a program running with access the attacker does not have. For example, a TCP service running on my server already has access to things an attacker in the internet does not have, namely my CPU, RAM and disk. If an attacker can confuse the TCP service into running a shell on some port, we have exactly the confused deputy problem, and capabilities never came into it. The attacker does not exist as a user on my server and therefore cannot have capabilities.

TL;DR: Security is hard. There is no one-size-fits-all solution. Choose a model and run with it. Smarter people than you or I have banged their head against that particular wall and it just refuses to fall.

Thanks for the infos. That was exactly the answer I hoped to hear.

I mean an "application with higher privilege" can alter the ACL is really bad? In all systems that I know of there's a higher privilege level (uid 0, root on UNIX) that can change groups / ACLs / whatever. For the records, VMS solves this by introducing the concept of the control ACE, aka. the ACL list has its own owner, who is allowed to change (control) the list. Each ACL might have a different owner. But to be honest, VMS also has a BYPASS ACE, meaning if any of the ACLs has that ACE, no security checks will be done, so that process with BYPASS will be able to modify other ACLs unconditionally (effectively equivalent of running as uid 0).

I don't know yet about ACE. I guess they are sort of "key rings" (structs/lists with ACLs)? My favourite search engine and Wikipedia didn't give me enough info about ACE or VMS-ACE.

EDIT: The owner principle doesn't sound like what I want to write.

I haven't yet decided how to implement:
(a) who may change the rights (I am planning that only the exokernel and the exokernel's superuser may change them)
(b) whether rights may be given away to any code you want (that doesn't s sound right to me)
(c) whether instances can inherit rights totally (like Genode does)

What I've planned so far:
- runs only 64bit, on x64 and only on UEFI.
- somehow encrypts the ACL
- doesn't give away rights control to any other part of the system.
- exokernel -> so the rest of the system can be a library OS and can have multiple subsystems.
- a list of instances and rights, as simple as I can make it without making it strongly insecure.

Greetings
Peter

[PeterX]

OK, I see now: The general direction of your replies is like "Don't try to solve security problems abstractly. Instead start coding with what you think is right and then discuss the concrete code."
So let's stop the discussion here.
I will start with what I mentioned (ACL exokernel) and then discuss concrete code problems here.

Happy hacking
Peter

[Schol-R-LEA]

Can you formulate a concrete problem that you see so that we can give a precise answer? All terms that you mention are kind of broad.

My question was general because I'm planning (and not yet coding) an exokernel. And I want to use ACLs for it.

Uhm, I am not sure if those two ideas are really compatible - the whole point of an exokernel is that it doesn't have those kinds of abstractions, and any security-type limitations are handled by limiting the resources accessible by the individual virtual machines (basically, the hypervisor can make it so that the individual virtualized program think that they are on a machine which only contains exactly the resources each requires, and nothing else). This is usually done when installing and configuring the individual programs, after which the exokernel would more or less leave the programs to their own devices - the only action the kernel does in normal operation is to multiplex the real hardware.

Anyway, getting back to ACLs versus capabilities... while the 'confused deputy' problem is the usual example of an advantage of capabilities (going back to some of the original papers describing capabilities), as the others state, this mostly amounts to moving the problem rather than eliminating it. The shuffling is generally agreed to help by limiting the window of vulnerability, but it is still there.

The real advantages of capabilities are that they formalize the whole security structure system-wide, they are much more finely-grained than a typical ACL structure, and most of all they move the security focus from 'user privileges' to 'process privileges'.

This last part is the important one, as this (as I understand it) is how it reduces the likelihood of a Confused Deputy - the privileges are held by the process, not the user, and there is a fixed, consistent means for transferring permissions without any user intervention necessary (a process may base the transfer on a user request, but in general, the user wouldn't have any role in the security system at all). The process in most cases has no information about the user other than its own process owner, which it was expected (when capabilities were first conceived) usually would not be the user.

It is helpful to recall that capabilities were originally intended as hardware checks to be performed on every memory or disk access, and that the main concerns they were meant to address were programming mistakes, with espionage - as in literal human spies acting on-premises trying to access a mainframe - being the next main interest. The modern security concerns hadn't even been seriously considered yet. The point is, they were designed to be entirely automatic, something the user couldn't even access short of meddling with the CPU hardware (back when CPUs were made from discrete components...).

Hardware capabilities were an academic study field in the 1970s, but fell out of favor in the 1980s because, first off, they were expensive to implement, and second, when companies such as Intel tried to implement them on microprocessor CPUs (the i432 being the most notable, but hardly only, such project), the photolithography processes of the day simply were up to the task. From time to time there's renewed interest in the topic, but as with most security issues, no one can be bothered with anything that will cost more or cause them inconvenience unless forced to.

While it wouldn't be difficult to implement today with modern integrated circuit processes, no one has the wherewithal to do so (Ivan Godard, discussing the Mill architecture: "It is not a capability architecture. I would love to do a capability architecture, I think that caps are the most wonderful thing in the world. I know how to build one; I don't know how to sell one. We're in the goal [sic] to make money.").

Methods for implementing software capabilities - mostly based on using a c-list kept in kernel memory, and only accessible though a system call - were developed originally as a stop-gap or intermediate stage, with the expectation that hardware capabilities would replace them once that had become economically feasible... which still hasn't happened, not because of cost but (as I said) no one wants to go to the trouble.

[PeterX]

Well, I'm not intenting to use VMs. Rather subsystems with sometimes direct access to hardware (and sometimes not). EDIT: This is easy to be misunderstood. I mean OS libs can access HW directly if they are the lowest level and have the permission.

OK, maybe when I use ACL I should not name it exokernel? But I still think it actually is more or less an exokernel. I mean, the ACL maybe an abstraction, but I'm not abstracting other things than security. And even that is perhaps not abstracting, but rather just limiting.

Can't ACL formalize the security? And can't they be fine-grained?

I am not 100% sure that I don't want user privilege managment. But I surely want to put it much more into process privilege management than user.

Happy hacking
Peter

[bzt]

I don't know yet about ACE. I guess they are sort of "key rings" (structs/lists with ACLs)? My favourite search engine and Wikipedia didn't give me enough info about ACE or VMS-ACE.

ACE is an Access Control Entry, one element of the Access Control List. It looks like you're right, there's not much information about VMS ACL online. Among other books, I've an old version of this book. Yes, old-school paper book, so I can't link it, sorry. This might shed some light on the topic: ACL in OPenVMS

EDIT: The owner principle doesn't sound like what I want to write.

I haven't yet decided how to implement:
(a) who may change the rights (I am planning that only the exokernel and the exokernel's superuser may change them)

The list owner provides a simple and configurable way to do this. It looks overkill that only superuser allowed to change the rights, think of a simple user file under home.

(b) whether rights may be given away to any code you want (that doesn't s sound right to me)
(c) whether instances can inherit rights totally (like Genode does)

These are question you have to answer yourself according to your design. The fact that you're taking these into consideration suggests you're on the right track!

- somehow encrypts the ACL

I would recommend against this. Checking permissions is a very common task, executed very very often. This would unnecessarily slow down your system. Instead I'd suggest using digital signatures: creating a digest of the list, then encrypting the resulting hash with an asymmetric algorithm. This way you can check the list's integrity, only programs with the proper key can modify the list, and yet you'll be able to read the list without overhead (it is enough to do the computational heavy asymmetric key check if/when the digest changes, otherwise you just do a simple memcmp on the digest).

Can't ACL formalize the security? And can't they be fine-grained?

Most definitely they can! ACL provides the finest-grained access there is! For example, you can have a normal user file under /home/joe/public/index.html, which can only be modified by joe, but has an WWW:R ACE so that the webserver can read it regardless of the groups and other permissions. And by creating pre-defined access lists, you can easily formalize it into role based security (one list for the administrator, one list for the operator, one list for group 1, another for group 2, etc.).

Cheers,
bzt

[Schol-R-LEA]

If you haven't already done so, I would recommend reading some of the research papers on capabilities (and in the case of PeterX, those on exokernels) before proceeding. I suspect that there are some significant misunderstandings on everyone's part (including my own, since I am certainly no expert on either topic).

I have always been of the opinion that the debate over ACLs vs. Capabilities is itself missing the real point, which is that they are complementary, rather than contradictory. Capabilities really don't cover the same types of security which ACLs are most often used for (e.g., user access - logins, action confirmations, and the like), while ACLs are sometimes misused for things which would be better handled with capabilities (e.g., anything which doesn't actually require user intervention - which most systems barely have any facilities for at all). ACLs are primarily best for user security; capabilities are for inter-process security.

At least, that is how it seems to me.

The other aspect of Capabilities which this discussion so far has missed is that they are (IMAO) better at isolating concerns. The process granting the capability doesn't need to keep a list of the tokens it has granted; only the process holding the token has that information, and the token can be passed to a different process without any intervention from the grantor. While this itself opens up a new way for the Confused Deputy problem to arise (if process A grants B a token, and B passes it to a process it shouldn't, then A becomes a Confused Deputy), but the system is supposed to have ways of checking for that - though I would have to re-read those papers I mentioned to recall how. The point is, the information about who can access what is localized with the one who needs the service, not the one providing it.

To put it another way, the difference between an ACL and a capability systems is who is keeping a list of what. The c-lists usually used for this are associated with the process holding them, and even the process itself can only access them through the kernel. This is why quajects are often compared to c-lists (and in Synthesis, implemented using c-list-like kernel structures) - in both cases, they are lists of operations to be performed, either as one-time keys to be applied or as functions to be performed, or both.

Since only the kernel can create the tokens for the grantor, or move them around from one holder to another, it limits the points of failure. This can be done with ACLs too, as bzt states, but in practice this never seems to be done - the programs are left to manage the lists themselves.

As for exokernels, I would hesitate to call anything which isn't a hypervisor an exokernel; indeed, the real relationship is sort of reversed, as most hypervisors are in effect a superset of what an exokernel can do (though the ability to share memory between different virtual machines is not common for hypervisors, as the main use of those is for multiplexing hardware between entire operating systems, and for compartmentalization of them to allow greater sandboxing).

The real difference between them is in how they are used, however. The whole point of an exokernel is that multplexing the hardware is the only thing it does. The ability to share library memory is somewhat secondary to this, a memory-saving hack which is not really all that valuable on modern hardware with their copious physical memory capacities. It is still worth doing, but it is not the defining quality of an exokernel, IMAO.

I also would add that exokernel systems as they are usually described are generally best used for servers and other systems with more or less fixed configurations - almost an updated form of batch processing, as it were, in that each program is mostly running in isolation with little or no common data shared between them (at least, not in system memory - they can easily share secondary storage, of course).

I would even go so far as to say that the main reason that we haven't seen an exokernel-seque hypervisor specifically for the purposes of running containerized programs, rather than rump Linux kernels loaded via Docker or Vagrant, is because, well, a container is more than just the program being run; a container also has all of the extra (and often extraneous) things which most modern programs need in order to run, as well as all the configuration and development tools needed to go with them, set up in a known-good state when the container is created. An exokernel designer would need to re-invent all of those wheels, and while the end result would probably be worth it, you would then need to convince people to adopt it... which as I have often stated, is a far harder problem than any of the technical aspects.

Which is also why exokernels present a bit of a challenge for desktop use, especially if you mean to have a GUI. While you could use an exokernel for a GUI desktop system... why would you? The typical desktop manager and environment has to be able to stick its fingers into almost everything which a GUI-oriented program does, with compositing, the widget library, or even basic facilities such as the clipboard. While you could do all of this on top of the exokernel, you'd in essence be running a second OS on top of the first - in other words, it would be more of a conventional hypervisor.

While there may be ways to make this work - I have some ideas in this direction, regarding applying virtualization to some of the Synthesis kernel's idea - for an otherwise conventional system, I am not certain that it would be worth it. Something to experiment with, to be sure, and I do intend to, but I won't be surprised if it turns out to be a dead end.

And now, I await word from a certain other member, who will no doubt go on a tear about the Evils of Virtualization and how pointless and wasteful it is.

[Schol-R-LEA]

I mean an "application with higher privilege" can alter the ACL is really bad? In all systems that I know of there's a higher privilege level (uid 0, root on UNIX) that can change groups / ACLs / whatever.

One of the aspects of capability-based security - and indeed, of any rational security system - is that there is no absolute frame of... sorry, wrong debate ... no process, kernel or otherwise, which has unlimited privilege. Unfortunately, avoiding this takes extra time and effort, so no real-world system has ever bothered, and we are stuck with a world where any program with root access can ream a system to its core.

I'd love to see this problem fixed, but I'm enough of a pessimist that I doubt this is going to change no matter how dire the consequences become, because people are people and war... war never changes...

(I've been playing far too much Fallout: New Vegas for my own good recently, having just finished the Old World Blues DLC story for it. Great game, BTW, and both GoG and Steam regularly put it - and the rest of the series except Fallout 76 - on sale. Just sayin'.)

[eekee]

One of the aspects of capability-based security - and indeed, of any rational security system - is that there is no absolute frame of... sorry, wrong debate ... no process, kernel or otherwise, which has unlimited privilege. Unfortunately, avoiding this takes extra time and effort, so no real-world system has ever bothered, and we are stuck with a world where any program with root access can ream a system to its core.

Ah, more evidence that Plan 9 is not a real-world system. Hostowner does get a lot of privilege in Plan 9, but it's limited to one machine by definition; running processes on the fileserver is not how you're meant to use it. You need hostowner access to the fileserver to get anything resembling root access to the files. Originally, the fileserver had a different kernel; it couldn't even run user programs and I don't think you could log in remotely. You had to physically type stuff on the fileserver console to disable permission checking.

[Schol-R-LEA]

One of the aspects of capability-based security - and indeed, of any rational security system - is that there is no absolute frame of... sorry, wrong debate ... no process, kernel or otherwise, which has unlimited privilege. Unfortunately, avoiding this takes extra time and effort, so no real-world system has ever bothered, and we are stuck with a world where any program with root access can ream a system to its core.

Ah, more evidence that Plan 9 is not a real-world system.

I don't know enough about Plan 9 to judge it. However, from you description below, it still sounds as if the permissions can be pretty broad, so IMAO, my statement still stands. I am talking about a system in which a given process only has exactly the permissions it requires, and user privileges - even administrator privileges - extend only to the data and programs which they need to be able to access for their various purposes.

Put it this way: if it is possible to access a program other than those required to manage the system from an admin account, then that system doesn't fit what I have in mind. I am guessing that this applies to Plan 9 given what you said. I can't imagine any general-purpose OS which does anything so inconvenient being a success (and yes, I am aware that Plan 9 isn't exactly meant for general purpose use in the sense that Windows, Mac OS X, or even Linux are; also, it has always been a niche system, but that has more to do with the general disinterest in distributed systems by commercial users - including, or perhaps especially, those who would most clearly benefit from it - than anything to do with either Plan 9 or its successor, Inferno).

[Gigasoft]

The process granting the capability doesn't need to keep a list of the tokens it has granted; only the process holding the token has that information, and the token can be passed to a different process without any intervention from the grantor. While this itself opens up a new way for the Confused Deputy problem to arise (if process A grants B a token, and B passes it to a process it shouldn't, then A becomes a Confused Deputy), but the system is supposed to have ways of checking for that - though I would have to re-read those papers I mentioned to recall how.

No, why would you think so? It shouldn't matter to A whether invocations come from B or some other process. In no case should the meaning of an invocation change such that an unintended resource is now being accessed. Thus, process B can not cause anything to happen by duplicating a token into another process that it couldn't also do by acting as a proxy for requests coming from the other process.