Subject: Re: [e-lang] capability myths demolished!

From: Ka-Ping Yee <ping@zesty.ca> · Date: Wed, 4 Dec 2002 02:53:42 -0600 (CST)

David Wagner <daw@cs.berkeley.edu> said:
> For instance, standard Unix systems have only limited support for this
> principle.  A process can be running as root, or as a non-root user.
> Root processes can relinquish some privileges by calling setuid() to
> become a non-root user.  However, this has a lot of limitations.  It is
> very coarse-grained.  It is not available to ordinary (non-root) programs.
> And so on.

Cees de Groot wrote:
> Linux has done a tiny step in the correct direction with kernel capabilities.
> For example, I have an appserver that's suid root, gives itself the
> capability to bind to low-numbered ports, then suid's to an unpriviliged user
> id. Somewhere in the high-level language code, later on, the socket is created
> and bound to port 80.

It should be emphasized that these are not "capabilities" at all. 
They are just a list of privileges that have been mistakenly
labelled "capabilities".  In a capability system, a program cannot
"give itself the capability" to do anything; it can only transfer
its capabilities to other actors, and does so by explicitly sending
them along communication channels. shap cg

I'm not even sure this is a step in the correct direction.   Yes,
it does allow one to write setuid programs that are somewhat safer
than the programs that can be written today, but at the expense of
further complicating the security model (does any one person know
everything that happens in fork() anymore?) and damaging the word
"capability".

> However, this is not POLA. That's be the capability to bind exactly to port
> 80. My appserver can bind to any low port and fool e.g. NFS servers and other
> systems that think ports <1024 are something special.

That's a granularity issue.   I agree that finer granularity is
desirable, but even if Linux "capabilities" had finer granularity,
it would still be the wrong model.

Even then, regardless of the granularity at which these privileges
might be specified,  all programs would still be restricted to the
particular boundaries and definitions imposed by the kernel, and
would be unable to refine or aggregate them as a capability system
with interposition would.

In summary, Linux "capabilities" are not POLA for three independent
reasons:  (a) POLA means authority isn't transferred implicitly,
(b) the chunks of privileges are too big, and (c) programs don't
have the power to truly uphold POLA even if they wanted to because
they can't refine the authorities they transmit.

-- ?!ng

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang