Re: Introducing CloudABI: a pure capability-based runtime for NetBSD (and other systems)

[David Young]

On Thu, Jun 25, 2015 at 03:11:51PM +0200, Ed Schouten wrote:
> Hello NetBSD hackers,
>
> Two weeks ago I gave a talk at BSDCan about something I've been
> working on for the last half a year called CloudABI[1]. In short,
> CloudABI is an alternative UNIX-like runtime environment that purely
> uses capability-based security, strongly influenced by Capsicum[2].

Ed,

It has always seemed to me that it will be easier for a user to form and
to operate a mental model for a capability system, especially if the
system makes the capabilities visible, than to model any rules-based
system. So capabilities have always looked like a good foundation for
building *usable* security.

Initially, I was very excited about Capsicum, "practical capabilities
for UNIX". But it seems like Capsicum isn't for users, it is for
developers: in the examples I have read, you have to modify a program's
source to make good use of Capsicum. That seems like an unnecessarily
high barrier to use.

That brings me to my question about CloudABI. It sounds like CloudABI
is aimed at developers, who would adapt programs to work with the new
run-time? Or is there an upside to CloudABI for users, too?

Dave

--
David Young
dyo...@pobox.com Urbana, IL (217) 721-9981

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

[Ed Schouten]

Hi Dave,

2015-07-24 1:07 GMT+02:00 David Young <dyo...@pobox.com>:
> Initially, I was very excited about Capsicum, "practical capabilities
> for UNIX". But it seems like Capsicum isn't for users, it is for
> developers: in the examples I have read, you have to modify a program's
> source to make good use of Capsicum. That seems like an unnecessarily
> high barrier to use.

I think that's simply a trade-off. By its original design, UNIX-like
systems don't offer enough protection for reducing the impact of
security bugs in applications running on top of the kernel.

Some of these systems attempt to solve this by using separate security
policy files (SELinux, App Armor, etc), while others try to solve this
by making the program itself be more clear towards the operating
system what it still wants to do in the future (Capsicum).

I'm more of a fan of the second approach, as it allows the rights to
be further reduced over time (defence in depth). Furthermore, a
separate security policy needs to be synchronised against the
configuration of the application. Say, if you adjust the root
directory of a web server, the security policy would need to be
adjusted in the same way to still grant access to it. Keeping this in
sync is hard.

I personally disagree that Capsicum isn't for the users, for the fact
that security policy based systems are actually the ones that put an
additional burden on the users. Capsicum is for the users, as the
users don't need to do anything special to gain security. The
developer already did that work for you.

> That brings me to my question about CloudABI. It sounds like CloudABI
> is aimed at developers, who would adapt programs to work with the new
> run-time? Or is there an upside to CloudABI for users, too?

I think it's aimed at both developers and users.

First of all, as the system is built around capabilities from the
ground up (read: all conflicting interfaces have been removed), the
advantage is that it becomes a lot more easy for developers to write
applications that actually work in such an environment.

For users the advantage is that they can finally run arbitrary third
party programs and be certain that these programs can't access
anything that hasn't been granted to the program explicitly. There is
no need for them to set up any jails or virtual machines manually.

--
Ed Schouten <e...@nuxi.nl>
Nuxi, 's-Hertogenbosch, the Netherlands
KvK/VAT number: 62051717