Creating a capabilities-based restricted execution system

[Serge Orlov]

"John Roth" <newsgroups at jhrothjr.com> wrote in message news:vvg0h93ue63c0b at news.supernews.com...
>
> Much of this thread has focused on "capabilities" and the use of
> proxies to implement capabilities. AFIAC, that's not only putting
> attention on mechanism before policy, but it's putting attention on
> mechanism in the wrong place.

I'm not sure why it should be discussed here since Sean refered
to E in the first post (http://www.erights.org/), so I think he's
comfortable with the policy defined by E? I think he has
missed the part that implementation should help as much as
it can prevent leaking capabilities from one security domain to
another. I pointed to that already.

>
> What I *haven't* seen in this thread is very much consideration of
> what people want from a security implementation.

I think Sean is talking about his own implementation. I didn't
see anywhere he said he's going to write general implementation
for other people. He said what he wants from his implementation.

> One problem I've been playing around with is: how would you
> implement something functionally equivalent to the Unix/Linux
> chroot() facility? The boundaries are that it should not require
> coding changes to the application that is being restricted, and it
> should allow any and all Python extension (not C language
> extension) to operate as coded (at least as long as they don't
> try to escape the jail!) Oh, yes. It has to work on Windows,
> so it's not a legitimate response to say: "use chroot()."

I don't see any unsolvable problems. Could you be more specific
what is the problem? (besides time, money, need to support
alternative python implementation, etc...)

-- Serge.