[cap-talk] Importance of fd based library API extensions?

[Jed Donnelley]

At 11:12 AM 1/19/2008, Rob Meijer wrote:
>On Mon, January 14, 2008 10:49, Jed Donnelley wrote:
> > At 01:07 AM 1/14/2008, Rob Meijer wrote:
> >>Working on some texts concerning the subject of POLA/POLP usage
> >>on mainstream operating systems using the multi process approach,
> >>I came to the insight that the main obstacle to this approach
> >>seems to have not much to do with incomplete kernel mechanisms or
> >>legacy 'program' code, but actually much more with the simple fact
> >>that existing 'libraries' mostly 'insist' on opening their own files,
> >>sockets, directories etc.
> >
> > Hmmm.  From my perspective I appreciate your insight, but I believe
> > the above somewhat overstates the case.  Suppose there were libraries
> > that accepted object references (e.g. open file descriptors) instead
> > of names for files and didn't insist on opening their own files as
> > you suggest.  Wouldn't there still be a problem with legacy code
> > that manipulated file names rather than descriptors at many other
> > levels?
>
>Yes, but it would become possible and much more simple to create a multi
>process version of an application.

I get some cognitive dissonance when I hear the term "multi process"
used in such a context.  For me the term "multi process" refers
the mechanisms for having multiple processors (CPUs) in a system
(perhaps cooperating as with a multiprocessor operating system).

You seem to be using that term in a very different manner.
I can only guess, but it seems to me you are using it to refer
to some flexibility in a program that might allow it to accept
either a name (e.g. of a file to open) or of an already open
file descriptor.  This is certainly possible (though uncommon
in my experience), but if that is what you are getting at,
how does the term "multi process" apply?

> > Also, even if programs communicated open file descriptors essentially
> > as capabilities, with current OS kernels such programs would still
> > be running as some "user" and would have the authority to open
> > files available to that user ambiently (i.e. without needing a
> > capability).  This is not POLA/POLP.

The usual way that people get closer to POLA with this approach
is to run programs as users (e.g. "nobody" in Unix) with very
few (the intent is none) other access permissions.  I believe this
is the approach that both Plash (for Unix) and Polaris (for
Windows) use.  Of course there are practical limitations.
E.g. in Unix world accessible files, perhaps Internet access, etc.

>If we assume something like AppArmor to be used for limiting access based
>on the process its executable, this must not necessarily be the case.

By "this" in the above I take you to mean that there should be
no "ambient" authority available to programs run under AppArmor?
Since AppArmor explicitly designates what permissions are
available to an executable, I presume it can, at least by
option, be zero based (that is, assume no ambient permissions).

>I argue that with libraries that allow the library user to open its own
>files etc, would allow multi process applications where most of the
>processes could go with the most simple of profiles for AppArmor or
>something like it.

Ah, now I pick up more on your intent with that "multi process"
term.  In the above I take it to mean what I would refer to
as "multi domain".  That is you are referring to separate
programs running (presumably in parallel, but not necessarily
on multiple processors), but in separate protection domains
and communicating.  Is that right?  This is along the lines
of how Postfix was programmed to have multiple processes
with separate authorities to cooperate to do much the same
work as sendmail does with a single process and one shared
authority set.

>That is where files and networking sockets are
>concerned, directory Fd's remain a separate issue.

Interesting perspective.  In Unix I would think that directories
could be treated pretty much just like files - just files that
happen to have other file names in them.  This is of course
very different from what I consider to be a "directory"
object in a capability system - an object that stores other
capabilities (like a c-list) except by name.  Such a directory
is a much more sensitive object from a security perspective
(it comes with power, matches and children), because access
to the directory provides access to all the capabilities
stored in it (perhaps with attenuation as with the "deep read
only" property discussed previously on this list, or something
like policy restrictions via a PDP, etc.).

--Jed  http://www.webstart.com/jed-signature.html