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

[John McCabe-Dansted]

On 9/3/06, Mark Seaborn <mseaborn at onetel.com> wrote:
> 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

Here is a UNIXy argument for allowing FDs to be passed around:

First, there isn't much point in preventing B from running
    A > F
and giving an FD for F to A, if B can still run
    A | cat > F
or an equivalent.

You could clearly stop "A | cat > F" from working, e.g. by removing
the cat binary. But if B can write to F and communicate with A, then
there is nothing you can do to stop B acting as the cat in the middle.

Second, passing rights around can be very important for security.

A common requirement for GUI apps is that they must be able to access
any document opened in the file open dialog box. The traditional way
of doing this is to allow to all apps to access all files in
~/Documents/ (or even ~/). As with Polaris, Plash only gives access to
those files opened in the file open dialog box. Unlike Polaris, Plash
works by passing in a FD for the files rather than copying files
around. This has obvious advantages for large files and concurrent
access.

An security policy that gives all GUI applications access to the
entire contents of ~/Documents is a cop-out, but a necessary cop-out
if static policies are used. Although not used as much as some
theorists would like, the ability to dynamically update the rights of
a process by sending FDs through sockets was an intentionally added
security feature of UNIX. To label this feature a bug and disable it
would be a step backwards, particularly for a project that aims to be
as close to UNIX as possible. We know that this "bug" cannot be
exploited, because if the process that fopen()ed the file was
untrustworthy, we are already lost*.

* Unless maybe the app is confined, chrooted or sandboxed.  B, then,
how did the FD escape the sandbox?

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia
"Those who do not study UNIX are doomed to repeat it"







It seems that you can enforce a security protocol that stops B passing
from passing an FD for F to A but you can't sI guess in unix
terminology this would be
   why try to prevent B from p "A >F"


-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia