Re: [patch 2.1.97] more capabilities support

Andrej Presern (andrejp@luz.fe.uni-lj.si)
Thu, 23 Apr 1998 20:51:31 +0200

Alexander Kjeldaas wrote:
> > An alternative way to do this is to use pure capabilities.
> >
> > Instead of keeping a list and then performing f(D) for objects that are
> > on the list, E could create a 'capability' to D and then give that out
> > to A and B. A capability identifies the object (D) _and_ describes the
> > action (f) that will be performed on D. When A or B want to excercise
> > their authority over D, they invoke the capability to D to trigger the
> > defined action.
> >
>
> To put this in some more context..
>
> File descriptors is the closest match to pure capabilities that we
> currently have in the kernel.
>
> When we open a file, we get a file descriptor which is a capability
> identifying the object _and_ the action(s) that can be performed on
> the object. This means that the kernel doesn't have to do extensive
> checks for authority on each read and write operation. It is an
> optimization. A file descriptor can be transferred from one process to
> another by going through the kernel (which we in most cases is what we
> want to do when we implement pure capabilities too, unless we want to
> play MMU tricks). A file descriptor can also be revoked.

Exactly. The similarity between a file descriptor and a capability is
quite striking. And isn't it intresting that considering the volume of
corespondence on BUGTRAQ that so little security problems have been connected
to file descriptors?

> So pure capabilities is a kind of generalization of something we are
> already familiar with.
>
> I have nothing against pure capabilities. It's a good idea, but I
> don't see why we shouldn't put POSIX capabilities into the kernel just
> because someone has made OSes which are based solely on pure
> capabilities. POSIX capabilities have been used for many years, pure
> capabilities are AFAIK only now being used on commodity hardware in
> experimental OSes. But there is nothing stopping anyone from
> implementing it in Linux. And when it is done, if they are fast
> enough, they will be able to emulate the current POSIX capabilities
> interface.

The reason why use pure capabilities instead of POSIX capability lists
is because capability lists suffer from similar problems that ACLs
suffer from. I have absolutely no doubt that time will come when those
problems will start to itch again and a new concept will be sought
after to solve them, a concept that has been proposed right now.

Besides, I really don't see a good reason why a clearly superior design
should not be implemented, especially considering the fact that both ACL
and capability list designs can be implemented on top of it, ensuring
compatibility with existing standards and old programs. Pure capability
based systems have been running commercial and military security aware
applications for over 20 years and have even been implemented on off the
shelf technology (such as IA32) for a number of times.

Don't get me wrong. I'm not trying to stop POSIX capability lists from
getting into the kernel. POSIX capabilities are a big improvement
compared to the current situation. I would just like to point out
security designs that are far superior than POSIX capability lists.
POSIX capability lists have only one purpose in the system: security.
While pure capabilities serve this purpose much better than POSIX
capability lists, they also provide extra bonuses, such as increased
performance, decreased complexity, better scalability, increased
flexibility and more robustness. To me implementing pure capabilities
seems like a win-win situation.

Andrej

-- 
Andrej Presern, andrejp@luz.fe.uni-lj.si






-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu