[cap-talk] Language and/or multi process/IPC security (prev: Windows Vista: security by admonition)

[David Wagner]

Rob <rmeijer at xs4all.nl> writes:
>As long as OS overhead is within acceptable bounds, modular reasoning
>can easily be moved out of the single process confines imho. If you are
>able to put each module in its own process you will end up with the same
>level of modular confinement as with language based security, the module
>itself could be broken even broken badly, but the modular confinement
>remains exactly the same.

In principle, absolutely.  (This is closely related to the notion of
"privilege separation".)  In practice, it is so cumbersome to decompose
your app into multiple processes that almost no one does so.  One of the
reasons that this is cumbersome is that there is a lot of marshalling
and demarshalling and synchronization needed to share state between
the components; it's not very easy to share access to a common data
structure or a common heap when you have multiple processes.  All that
marshalling and unmarshalling feels like unnecessary annoyance that
doesn't actually contribute to the functionality of the application ,
so it's surprising that developers are reluctant to spend a lot of time
on that "wasted code".  This is one place where language-based methods
can greatly reduce the "annoyance factor" for the developer.

>* Language based security limits the number of (often very expresive)
>  languages that can be used and limits the reuse of old proven codebases.
>  It also limits the posibilities of getting critical (and static) modules
>  formaly certified and keeping them certified across multiple incarnations
>  of the overall system.

Yes.  I'm not sure how serious the limits on reuse of old codebases are.
Usually, legacy application do not have a POLA-compatible architecture and
need to be re-architected if you want them to respect POLA and capability
principles.  If you're going to rewrite the app, you might as well rewrite
it in a safe language while you're at it.  But the limits on the number
of languages that can be used are real and significant.  I don't follow
what you're referring to when you mention difficulties with certification.

>* multi process/ipc based security ads high OS overhead when modularity
>  is caried to its full extend, or ads the described integrity validation
>  problems when modules (processes) are allowed to have a relative high
>  level of complexity.

Also, there is a lot of overhead for the developer with this approach.
Writing applications that are decomposed into multiple processes like
this is annoying, and it is very difficult to convince developers to
do so.  Just look at the amount of pain that went into privilege
separation of ssh, for instance; it is no surprise that we don't have
many app developers lining up to sign up for that style of development.

Language-based methods make it easier to construct security boundaries
between mutually distrusting modules, and I hope the result will be that
programmers will construct more of these security boundaries and decompose
their app into finer-grained modules (and thus do a better job of
respecting POLA).