On 26.09.2010 19:38, Perry E. Metzger wrote: > On Sat, 25 Sep 2010 13:36:18 +0200 Jean-Yves Migeon > <jeanyves.mig...@free.fr> 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 >> programs." > > 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). -- Jean-Yves Migeon jeanyves.mig...@free.fr
