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

[Brett Cannon]

On 6/24/07, David Wagner <daw at cs.berkeley.edu> wrote:
> 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.
>

Great!  Glad to hear both answers.

> 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 will have a read.

> 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.
>

I will read those as well.

> 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.

Right.  Trick is how to possibly do this in an automated fashion.  =)

Thanks for the information, David, I really appreciate it.  I will
continue to keep people updated as stuff progresses (currently still
researching and manually refactoring code to test out various
approaches that can be taken).

-Brett