[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Capsicum: practical capabilities for UNIX
On 26.09.2010 19:38, Perry E. Metzger wrote:
> On Sat, 25 Sep 2010 13:36:18 +0200 Jean-Yves Migeon
> <jeanyves.migeon%free.fr@localhost> wrote:
>>> The second concern is related to the first:
>>> a Capsicum sandbox doesn't simulate access to the global
>>> namespace for the purpose of unmodified programs calling, e.g.,
>>> open(2)---can it? The authors of the Capsicum paper are already
>>> thinking about the question (see section 4.3, "gzip"); I'm eager
>>> to see what they come up with.
>> IMHO, that's the biggest concern. And I can't see how they could
>> come up with a solution other than "rewrite/refactor whole
> Actually, it is pretty easy for most systems programs to retrofit what
> you want. It is a lot harder for arbitrary programs, but that's
> another story.
I don't think so. For "small", "trivial" programs, like those used for
hashing, compress/uncompress, it is indeed easy to retrofit.
But if you go for programs like web browsers, web/application servers,
databases, or even any GUI program (PDF readers, did I say browsers?),
it is a lot less trivial to bring a capability model in.
>> I, for one, welcome our new systrace overlords.
>> oops :)
> Systrace is a MAC-like system. It is NOT a capability architecture.
Never said the opposite. Don't remove the part I was quoting just above :)
On 24.09.2010 21:46, David Young wrote:
>> For consistency, user confidence and convenience, I'd like to see a
>> wrapper program or shell built-in, "capsicum [capabilities] [program
>> [arguments ...]]", that creates a sandbox, grants it the mentioned
>> <capabilities>, and starts in it the given <program> with the given
>> <arguments>. Maybe that wouldn't be hard to do. Maybe there's a better
>> way, too. Your thoughts?
Doesn't it read like using "capsicum" as a "systrace" replacement?
>> More problematic: each mainstream OS has now its own "OS
>> compartiment model".
> This isn't per se a compartment model.
Of course not. But capabilities will mostly get used as one, especially
when considered as a controle message (cmsg API) replacement.
>> Solaris has zones, FreeBSD has jails, Linux
>> distros have dozens (containers now?), and so on. I just hope that
>> we do not end up with a capability API different for each OS: that
>> would hamper portability, and restrain most third party developers
>> from using it.
> Another reason, I think, for adopting Capsicum rather than reinventing
> the wheel. I think it is a set of good ideas.
I agree. What I liked about Capsicum is that you can run capability
applications side by side with regular POSIXish/Unix applications,
rather than requiring porting POSIX above a capability based
infrastructure. Feels "smoother" (although many would disagree with me
on that part).
Main Index |
Thread Index |