<html>
<body>
At 08:17 AM 8/31/2008, Toby Murray wrote:<br>
<blockquote type=cite class=cite cite="">On Sun, 2008-08-31 at 07:37
-0700, Sandro Magi wrote:<br>
> 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.<br><br>
I tend to view the Unestos design from [1] as an idealised marriage
of<br>
UNIX and a capability-based OS that provides strong POLA support
whilst<br>
being recognisable to all those familiar with UNIX.<br><br>
[1]<br>
<a href="http://www.usenix.org/event/hotos05/final_papers/full_papers/krohn/krohn.pdf" eudora="autourl">
http://www.usenix.org/event/hotos05/final_papers/full_papers/krohn/krohn.pdf</a>
</blockquote><br>
I found this paper interesting enough that I'll share some notes from
reading (sequential and loosely edited - be forewarned):<br><br>
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."<br><br>
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?).<br><br>
At this point they mention weaknesses in the capability design:<br><br>
"In Section 4, we discuss shortcomings in this proposed
design:<br><br>
A. system weaknesses might still allow vulnerabilities to spread,
(loose capabilities), and<br><br>
B. process-sized compartments are too coarse grained.
(seemingly a performance issue which I would say is addressed by ocap
languages)<br><br>
<br>
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."<br><br>
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,
<b>so the launcher must run as root</b>."<br><br>
<br>
3. Particularly damning of POLP efforts in modern operating systems
is their comment:<br><br>
"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."<br><br>
I agree with this criticism. Others?<br><br>
<br>
4. Nice to see the Polaris reference [30]<br><br>
<br>
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,<br><br>
"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."<br><br>
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,<br><br>
"...virtualizable system calls enable interposition. If an
untrustworthy process asks for a sensitive<br>
capability, a skeptical operator can babysit it by handing it a pipe to
an interposer instead."<br><br>
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:<br><br>
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.<br><br>
Terminology corrections gratefully accepted.<br><br>
<br>
6. This section of the paper under 3.2 "Naming and Managing
Capabilities" puzzles me somewhat:<br><br>
"...Traditional capability systems such as EROS favor global,
persistent naming, but persistence has proven cumbersome to kernel and
application designers [27]."<br><br>
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:<br><br>
"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."<br><br>
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).<br><br>
<br>
7. Regarding 3.3 "OKWS Under Unestos", it seems to me
that OKWS under a simple OCap system is even simpler.<br><br>
<br>
8. Regarding "4 FINE-GRAINED POLP WITH MAC": The
start with this somewhat enigmatic statement:<br><br>
"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."<br><br>
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.<br><br>
<br>
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.<br><br>
<br>
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."<br><br>
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?<br><br>
<br>
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.<br><br>
<br>
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.<br><br>
<br>
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"??<br><br>
<br>
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?<br><br>
<br>
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?<br><br>
<br>
Conclusion:<br><br>
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.<br><br>
Think there's any chance?<br>
<x-sigsep><p></x-sigsep>
--Jed
<a href="http://www.webstart.com/jed-signature.html" eudora="autourl">
http://www.webstart.com/jed-signature.html</a></body>
</html>