[cap-talk] Unestos paper notes (was: Re: More Heresey: ACLs not inherently bad)

[Jed Donnelley]

At 08:17 AM 8/31/2008, Toby Murray wrote:
>On Sun, 2008-08-31 at 07:37 -0700, Sandro Magi wrote:
> > Note that securable ACL systems and their relationships with 
> capabilities has been discussed many times before on cap-talk, in 
> particular as applies to systems with private namespaces. Eric 
> Raymond started a discussion in 2002 which is similar to what Shap 
> proposes below, regarding namespaces and Plan 9 [1]. The whole 
> thread is interesting, as it hashes out many problems with UNIX 
> semantics and private namespaces.
>
>I tend to view the Unestos design from [1] as an idealised marriage of
>UNIX and a capability-based OS that provides strong POLA support whilst
>being recognisable to all those familiar with UNIX.
>
>[1]
>http://www.usenix.org/event/hotos05/final_papers/full_papers/krohn/krohn.pdf

I found this paper interesting enough that I'll share some notes from 
reading (sequential and loosely edited - be forewarned):

1.  "A first approximation of a POLP-friendly system is one based on 
capabilities, discussed in Section 3. Though capabilities have 
historically flummoxed application designers, we present a more 
familiar interface, based on the Unix file system."

Is there any evidence that 'capabilities have flummoxed application 
designers'?  I don't recall reading any papers where application 
designers complained about the capability interface.  Do others?  I 
would be very interested to see such complaints (issues, etc.) as any 
such would cut into my argument that the main difficulty expressed 
with the use of capability systems has been the "loose capabilities" 
problem (I may have forgotten the agreed upon name for this problem - 
reminder?).

At this point they mention weaknesses in the capability design:

"In Section 4, we discuss shortcomings in this proposed design:

A.  system weaknesses might still allow vulnerabilities to spread, 
(loose capabilities), and

B.  process-sized compartments are too coarse grained.  (seemingly a 
performance issue which I would say is addressed by ocap languages)


2.  Here is a quote I found amusing: "System administrators with 
enough patience and expertise can chroot or jail standard servers 
such as Apache [1], BIND [3] and sendmail [26], though the process 
resembles stuffing an elephant into a taxicab."

Amen to that!  I agree with their criticisms of this 
approach.  Particularly nasty are problems like they discuss with 
their OK Web Server such as: "The chown call in Step 5, the chroot 
call in Step 6, and the setuid call in Step 7 all require privileged 
system access, so the launcher must run as root."


3.  Particularly damning of POLP efforts in modern operating systems 
is their comment:

"Other systems use similar techniques to solve related problems. 
Examples include remote execution utilities such as OpenSSH [23] and 
REX [10], and mail transfer agents such as qmail [2] and postfix 
[21]. Considering these applications and others, a trend emerges: in 
each instance, the intricate mechanics of privilege separation are 
invented anew. To audit the exact security procedures of these 
applications, one must comb tens of thousands of lines of code, each 
time learning a new system. Even automated tools that separate 
privileged operations [5] require root access."

I agree with this criticism.  Others?


4.  Nice to see the Polaris reference [30]


5.  The section "Unix as a Capability System" I found 
interesting.  Particularly their use of the term "virtualizable."  I 
don't believe I've ever heard that term used in that form 
before.  There they say,

"Processes are usually indifferent to whether a file descriptor is a 
regular file, a pipe to another process, or a TCP socket, since the 
same read and write calls work in all three cases. In practical 
terms, virtualization simplifies POLP-based application design."

Is the term "virtualization" often (usually) used with the above 
meaning.  I don't know of a better term, but virtualization seems so 
heavily overloaded that I would hope for a better term.  Shortly 
after the above the paper says,

"...virtualizable system calls enable interposition.  If an 
untrustworthy process asks for a sensitive
capability, a skeptical operator can babysit it by handing it a pipe 
to an interposer instead."

If that is what they mean by "virtualization" I consider that a 
different phenomenon.  That is what I've heard termed the "insertion" 
property, e.g. from:

F. A. Akkoyunlu, K.Ekanadham, R. V. Huber, "Some Constraints and 
Tradeoffs in the Design of Network Communications," Proceedings of 
the Fifth Symposium on Operating System Principles, 1975, Vol. 9, No. 
5, pp. 67-74.

Terminology corrections gratefully accepted.


6.  This section of the paper under 3.2 "Naming and Managing 
Capabilities" puzzles me somewhat:

"...Traditional capability systems such as EROS favor global, 
persistent naming, but persistence has proven cumbersome to kernel 
and application designers [27]."

Is the above true?  Isn't it the persistence of active elements 
(processes, active objects) that have proves "cumbersome" (actually a 
tradeoff)?  I haven't heard of any cumbersome aspects of persistent 
naming of objects.  They continue:

"Instead, we advocate a per-process, Unix-style namespace. Under 
Unestos, P1 makes capabilities available to P2 as files in P2's 
namespace. Suppose P1's namespace contains a tree of files and 
directories under /secret, and P1 wishes to grant P2 access to files 
under /secret/bob. As in Plan 9 [20], P1 can mount /secret/bob as the 
directory /home in P2's namespace.  Unlike in Plan 9, the state 
implicit in the perprocess namespace is handled at user level, and 
the kernel only traffics in messages sent to capabilities. For 
example, when the process P2 opens a file under /home, the user level 
libraries translate the directory /home to some capability C.  The 
kernel sees a LOOKUP message on C."

I don't understand what is going on in the above.  Are they 
advocating that the kernel support separate Unix-style name spaces 
for each process?  When they suggest that P1 'mount' /secret/bob as 
the directory /home in P2's name space it seems to me they are 
overreaching a bit.  Why should P1 control names in P2's 
environment.  To me it seems more effective for P1 to simply send a 
"capability" to /secret/bob to P2.  P2 can "mount" it anywhere it 
wishes.  The modularity is preserved while allowing P2 to manage it's 
own name space (except within /secret/bob - wherever that is based in 
P2's name space).


7.  Regarding 3.3 "OKWS Under Unestos", it seems to me that OKWS 
under a simple OCap system is even simpler.


8.  Regarding "4 FINE-GRAINED POLP WITH MAC":  The start with this 
somewhat enigmatic statement:

"Applications in Unestos can only express security policies in terms 
of processes, but processes often access many different types of data 
on behalf of different users. A security policy based on processes 
alone can therefore conflate data flows that ought to be handled separately."

This is the first place where I've seen the notion of a "user" 
(seemingly a person) introduced.  They seem to be suggesting that 
"user"'s own processes, so that it's impossible to have a process 
acting on behalf of multiple users, because (I'm guessing) the owner 
of the process would have access to everything the process does - 
including that which should belong to other users.


9.  "This section extends Unestos to a new system, Asbestos, whose 
kernel uses flexible mandatory access control primitives to enforce 
richer end-to-end security policies."  Sounds exciting.  I'm 
skeptical, but still exciting.


10.  Regarding, "4.1 Complete Isolation -  One possible approach to 
better isolation, which we call complete isolation, is to prohibit 
server-side processes from speaking for multiple users."

Their notion of "users" and the 'speak for' relation is puzzling to 
me.  I don't think I understand what they mean.  Do others?  For me 
(in a stictly capability sense) a "user" is a person interacting with 
a system (e.g. with a keyboard, mouse, through a communication 
channel, etc.).   In the paper these authors seem to be using the 
term "user" and the 'speak for' relation in a more internalized 
implementation sense (e.g. as with Unix processes being owned by 
users).  Unfortunately, as they try to separate active entities 
(continuing to call the "processes") that run programs with POLA the 
internal implementation of "user" that Unix uses gets in the way.  Is 
that what they are concerned about?


11.  Later in 4.1, "With each additional process that speaks on 
behalf of multiple users comes additional access control checks. If 
application programmers forget or misapply any of these checks, the 
system can leak sensitive data to attackers." - They are having 
'application programmers' do their own access control checks to 
insure that no sensitive data is leaked to attackers?  Isn't the 
problem that POLA tries to address the concern that it is the 
"application program" (controlled by an attacker) that is the 
concern.  I'm afraid I'm also lost here a bit.


12.  Regarding: "...compartments apply at the fine-grained level of 
individual memory pages, so that a single process can act on behalf 
of mutually distrustful users without fear of leaking data among 
them." !!?!  Further: "If the sub-process errantly accesses data in 
V's compartment, the read or write will fail, since U and V occupy 
incomparable compartments."  I don't understand how the proposed 
"sub-process" mechanism works.  Sub-processes apparently share parts 
of their memory space with other "sub-processes", but I don't 
understand how the lattice mechanism is enforced.


13.  "...since demux created the user compartments, it can sanction 
trusted declassifiers to traverse them."  Woo hoo!  Who controls 
"demux"?  This is still considered "MAC"??


14.  From the "related work" section:  "...ports in microkernel 
systems are coarse as capabilities go; for instance, a process can 
have a capability for the file server but not for a particular 
directory."  (or file presumably).  I guess I can accept this 
statement for many of the Ports discussions.  To me Ports always 
seemed like capabilities that couldn't distinguish between objects 
within a single server.  E.g. capabilities with no data to 
distinguish entries into a single server.  Why would anybody want to 
so limit their "capabilities" to "ports" when the loss is so costly 
and adding the additional information would be so trivial?


15.  A general comment about the paper at this point:  It seems to be 
using the term MAC for what we refer to as "confinement".  The 
distinction is that in a capability system that supports confinement 
if process (active object) A has a communication channel to process B 
in the form of a capability and A has a communication channel to C in 
the form of a capability then A can send C to B.  My understanding if 
MAC is that it disallows such communication.  When they refer to MAC 
in this paper do they refer to what we mean by MAC (beyond 
confinement, not allowing communication of capabilities through 
channels allowed by the confinement mechanism) or do they mean what 
we mean by confinement?


Conclusion:

It would be really great to get a bunch of these folks into a room 
with a bunch of us (e.g. the HP Friday meetings) and a white 
board.  It may be just my ignorance of their terminology and 
background, but to me it seems that there are a bunch of issues that 
are being discussed at cross purposes, partly because of terminology 
differences (e.g. MAC and confinement, "virtualization" vs. 
insertion, the notion of a "user", etc. - as discussed above).  I 
think it would be terrific if we could get people interested in these 
topics together in a room, hash out the issues, and write up a set of 
notes that could be referenced for future papers on these topics 
(mostly POLA).  The current fragmentation seems sad and 
counterproductive to me.

Think there's any chance?

--Jed  http://www.webstart.com/jed-signature.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20080831/55f4993e/attachment-0001.html