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

Rob rmeijer at xs4all.nl
Wed Jun 7 04:35:19 EDT 2006


> The reason that memory safety makes it easier to reason about program
> behavior is that it enables modular reasoning.  Modular reasoning means
> that can look at part of the program (e.g., the implementation of one
> module, along with the specification and types for the modules it calls or
> is called by) and draw some conclusions about how that module will behave,
> without having to look at the rest of the program.  Modular reasoning is
> not possible in a non-memory-language, because it is always possible that
> the part of the code you didn't look at could tamper with the private
> state (or even modify the running code) of the part you did look at.

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.

I believe both multi process and language based methods have their
advantages and their price:

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

I am not claiming that multi process/ipc based security is better than
language based security. but even if I would agree that language based
security would always be superiour, I believe that it is and remains in
any case a second to the point of capability security of either IPC or
language.

Rob



More information about the cap-talk mailing list