[e-lang] comparing privilege separation to POLA fair?

[David Wagner]

Brett writes:
>Anyway, my supervisor and I realized that perhaps refactoring
>for obj-cap (as I have brought up before) could be viewed as privilege
>separation where separation was now provided by language-level module/object
>boundaries rather than OS-level processes.

I agree with this characterization.  This seems like a fair
comparison to me.  I too have made the same comparison when trying
to explain the purpose for obj-caps, and in one recent grant proposal.

No, I don't know of any published paper that makes this comparison.

The paper by Niels Provos is a good starting point on privilege
separation.  Also read up on the architecture of Dan Bernstein's qmail.
I've heard this Steve Bellovin call this modular decomposition for
security.  (His point is that standard advice has often been to choose
how to decomposize your system into modules to maximize ease of code
maintenance and extensibility, or for performance, or for features;
whereas he advocates also making security a leading consideration when
choosing a decomposition into modules.) See, e.g.,
  http://www.cs.columbia.edu/~smb/talks/security-softeng/security-softeng.ppt

I would characterize privilege separation as a topic that is
incredibly important for secure system design, but alas, there isn't much
published research on it -- probably because it's been hard to figure
out how to attack it as a research problem, rather than as a software
engineering problem.  I think one can find more use of privilege separation
in practice than one can find written about in the literature.

Also, I think the motivation behind sandboxing, separation kernels,
MILS, virtual machines, and so on, has often been driven by similar
considerations.  See, e.g., Rushy's separation kernels, or the line of
work on secure sandboxes (I'm fond of Janus and follow-on papers, but I'm
biased given my involvement with Janus).  Those papers don't always make
the application to secure software design clear, but I suspect many of us
had at the back of our mind that these sandboxes provide a primitive that
system architects could use to do a better job of privilege separation.
See also Dan Bernstein's web pages, where he talks about, e.g., running
a decompressor in a separate process that is strictly limited so that
it can perform only computation and not any side effects.  See also
Linux seccomp.

One key difference between the standard view of privilege separation
and obj-cap systems is the granularity is very different.  In the
standard view of privilege separation, the OS is the only tool we
have for limiting the privileges assigned to a program.  Therefore,
standard privilege separation is based around decomposing the application
into a few different processes that each run at a different level of
privilege (i.e., where they are assigned different rights in the OS access
control schema).  That leads to coarse decompositions: commonly one might
separate the application into two processes (e.g., priv-separated ssh),
or, if you are Dan Bernstein, into a half a dozen processes or so.  In
comparison, the language-based obj-cap solutions try to enable much
finer-grained decomposition, and try to make it easy for programmers
to decompose into many small domains of authority, without forcing
them to go through annoyances of marshalling, demarshalling,
synchronization, etc.