[cap-talk] [Apparmor-dev] [ANN] FastRPC, a continuation of imsep

[Mark Seaborn]

[CC'ing to cap-talk in case others want to add anything to this
discussion.  The background is that AppArmor was changed so that file
descriptors cannot be delegated between processes.]

Crispin Cowan <crispin at novell.com> wrote:

> >> This is the core abstraction of the AppArmor policy model, and we
> >> would be inconsistent if a program was allowed to access files
> >> outside the policy merely because the FD was provided in an unusual
> >> way.
> >>     
> > It is not inconsistent if you base your analysis on authority (de
> > facto powers) rather than privileges (de jure powers).  I am taking
> > the terminology here from "Paradigm Regained: Abstraction Mechanisms
> > for Access Control" (http://www.erights.org/talks/asian03/).
> >   
> Uh, ok. I have seen people make the distinction between "least
> privilege" and "least authority" before, but I have never understood it.
> Your distinction between de jure/principal/privilege and
> defacto/practice/authority doesn't help me much.

OK, I will explain this in more detail.  Here are some definitions,
paraphrased from the paper mentioned above.  Feel free to disagree.

A process's privileges are the actions it can perform on objects it
can directly access, by direct requests to the kernel.  "Permission"
means the same as "privilege".

A process's authority describes the actions the process can cause to
be performed on objects it can access, either directly by permission,
or indirectly by permitted interactions with other processes.

Example 1:

Suppose I run a Web server to serve foo.html.  The Web server process
has permission to access foo.html: it can open() the file, and read()
from it.

A process with network access running on another machine does not have
permission to read foo.html, because it is running under a different
kernel that does not even know about foo.html.  However, this process
does have authority to read foo.html, because it can send a request to
the Web server, which will send back a copy.

Example 2:

On Windows, Polaris provides a way to run applications such as Excel
so that the application can read and write the file it was launched to
edit, but not any of the user's other files.  It does this by creating
a new user account under which to run the application.  When launching Excel
to edit Sheet.xls, Polaris copies Sheet.xls to a directory accessible
by Excel, and starts Excel on the copy.  Polaris monitors the copy of
Sheet.xls, and when it notices that it has been modified, it copies
the modified version back, overwriting the original Sheet.xls.

In this scenario, Excel does not have the privilege to read or write
the original Sheet.xls, according to the Windows' ACLs.  However, it
does have the authority to read and write Sheet.xls, because Polaris
performs these actions on its behalf.

[See http://www.hpl.hp.com/personal/Alan_Karp/polaris.pdf]

Example 3:

Consider two processes running under AppArmor:

Process A has permission to write to file F, as a result of the
profile it is running under.

Process B does not have permission to write to file F, but it does
have permission to communicate with process A (via a socket).

Process B wants to write to file F.

Process A wants process B to be able to write to file F.

The two can co-operate/conspire to allow B to do this:
B sends requests to A (via the socket) to write to the file,
and A does so on B's behalf.
i.e. Process A proxies access to the file.

Process B therefore has the authority to write to file F, even though
it does not have permission.

Process A has the ability to revoke this authority by ceasing to
follow B's requests, but until then process B has that authority.

This "Communicating Conspirators" situation is discussed here with a
nice diagram:
http://www.erights.org/elib/capability/conspire.html


> In human society, there is lots of wiggle room between what the law
> permits and what people actually do; many people speed, jay walk,
> and cheat on their taxes. In computer security systems, there is no
> such difference:

> the only things that are considered "secure" are those that have
> enforcement mechanisms, so principle and practice appear to be the
> same.

I agree.  Preventing delegation of authority between processes that
can communicate and want to share the authority happens to be
something that cannot be enforced.


> >> I can't speak for what the SELinux developers intended. What the
> >> AppArmor design intended was that the policy for the program receiving
> >> the FD should describe all of the files it can access, regardless of how
> >> it came to access them.

(I was taking "all of the files the program can access" to be an
authority property.)
   
> > The policy for the program receiving the FD cannot itself limit the
> > set of files that the program can access.  Another process can
> > delegate it the ability to access a file by proxying requests
> > (assuming that the two processes are able to communicate with each
> > other).
>
> "Cannot"? I'm afraid that is precisely what AppArmor does. There is no
> way for a program confined by AA to delegate a privilege,

Assuming s/privilege/authority/:

If the program is unable to communicate with other untrusted processes
(i.e. "confined" in the sense of the Confinement Problem), then yes,
it cannot delegate authority.

However, if it can communicate with other processes it can potentially
delegate authority to them by proxying, i.e. by performing actions on
behalf of other processes.

I guess I should ask, how does AppArmor treat file descriptors created
with pipe() or socketpair()?  Are there restrictions on communicating
across pipes/sockets?


> > To take the concrete example of an image decoder process, there are
> > two ways you can implement this in a system like AppArmor:
> >
> > 1) Give the process privileges (as defined by the access control
> >    system) that are minimal, and dynamically grant it further
> >    necessary authority by proxying or similar means.  For the image
> >    decoder, this might mean sending a copy of the image to the process
> >    via a socket.  This is secure (i.e. the process is granted the
> >    minimum necessary authority), but inefficient.
> >
> > 2) Give the process excess but sufficient privileges, and do no
> >    proxying.  This might mean granting access to all *.png files.
> >    This is efficient (because the process can use read() to read the
> >    file directly from the FD), but less secure (because the process
> >    can access files it doesn't need to be able to access).
> >   
> Ok
> .

Which of these would you choose to implement Mike Hearn's image
decoder example?

> I am not saying that object capability systems are bad. I like them. But
> AppArmor had a different design objective than EROS did. AA was designed
> to achieve reasonable least privilege with little effort and no
> application changes. EROS was designed to achieve tight least privilege
> using a new programming paradigm that requires substantial application
> changes, if not complete re-writes.

I appreciate what your aims are with AppArmor.  I wasn't intending to
discuss the whole system, I just wanted to explore this issue with
file descriptors.  I think the prohibition on delegation of file
descriptors will make certain delegation patterns a lot harder without
providing any enforcable gain in security.

Cheers,
Mark