Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Christopher Lemmer Webber]

First off, I should mention that rain1 reminded me about OpenBSD's
Capsicum and the Capsicum for Linux project, which I had mostly
forgotten about:
  http://www.capsicum-linux.org/

Capsicum brings file descriptor based capabilities, and this is a
reasonable intermediate approach.

Shill is an ocap (object capability) supporting shell using Capsicum:
  http://shill.seas.harvard.edu/

Ricardo Wurmus writes:

> Hey,
>
>>  - In terms of software, currently we run on ACL-heavy systems, which
>>    are well known to be insecure designs:
>>      http://waterken.sourceforge.net/aclsdont/current.pdf
>>    If a computer program behaves badly, it shouldn't be able to do any
>>    more damage than the smallest amount of authority it should need to
>>    run.  Currently programs run with the full authority of the user.
>>    This means that a tiny code flaw in even the most trivial package
>>    can lead to complete user compromise.
>>
>>    In the long run, we'll want to support object capability based OS
>>    designs which follow the principle of least authority, so a program's
>>    vulnerabilities will be limited in scope.
>
> I agree, which is why I think that in the short term we should look into
> doing more work on SELinux policies (hear me out, please).  SELinux
> already exists and it provides an implementation of mandatory access
> control.  The big picture idea is: processes and files are assigned to
> certain domains where only certain access types are permitted and the
> kernel enforces these declarations.  Processes can transition from one
> domain to another only according to policies.
>
> SELinux certainly isn’t pretty, but it isn’t quite as complicated as the
> bad documentation out there makes it seem.
>
> I was thinking that we could have an internship (GSoC or Outreachy)
> project to implement support for SELinux in Guix, including the design
> of an extensible policy scheme.  I think Guix is uniquely suited as the
> foundation of an understandable SELinux system.  (Think of how the
> existing system service framework could be extended to provide
> context-specific SELinux policies.)

I'm not a big fan of SELinux because it's using an RBAC style system,
which is like a more fine grained ACL.  It's still a centralized
authority model, non-composable, and isn't as secure as a capability
security type approach.

I said this on IRC but:

<dustyweb> E in a Walnut has something to say about that
<dustyweb> > With tools like access control lists and firewalls, we engage in
           "perimeter defense", which is more correctly described as "eggshell
           defense". It is like an eggshell for the following reason: while an
           eggshell may seem pretty tough when you tap on it, if you can get a
           single pinhole anywhere in the surface, you can suck out the entire
           yoke.

Source: http://www.skyhunter.com/marcs/ewalnut.html

My personal view is that ACL'ish / RBAC'ish systems are the wrong
approach.  I suppose if someone wants to put effort into this direction
I don't object, unless it starts to complicate our tooling.  But for
focusing our efforts what I think we should do is work towards a better
long-term security approach of supporting object capability operating
system ideas.

>>    - Well, GNU Hurd is a microkernel + ocap system (while also trying
>>      to be POSIX compatible).  Manolis has done much good work in
>>      helping to make that a more feasible option for Guix users.
>
> I’d love to get us closer to being able to run the GNU system with the
> Hurd and Guix underpinnings.  Unfortunately, Hurd is not considered a
> priority by GNU, which shows in the lack of support for modern hardware.

Yes, this is unfortunate.

>> As a side note, if we don't have both together (libre hardware + ocap)
>> and we just have microkernel + ocap systems on top of proprietary
>> hardware, especially heavily "vendor controlled" systems, we could end
>> up much more screwed than we are even in our current systems, which is
>> why I think it's critical that we engage these things.
>
> I don’t understand this.  Why would the situation with microkernel +
> ocap on top of proprietary hardware be *worse* than the current
> situation of a monolithic ACL-based system on top of equally proprietary
> hardware?

The problem is that a much better implemented system will be harder to
break out of.  Right now many people "jailbreak" systems so they can
install free software on them.  We want to build watertight security
systems so that when users *control their hardware*, the programs on
their machines cannot do damage that they shouldn't be able to do.

But if the same watertight security system was applied but the lowest
capability layers were out of the user control, it might not be possible
to break free.

We can already see some of this today.  My understanding of why Intel
won't release a chip without ME, for instance, is that it's key to the
DRM systems that enforce playback of blue-ray players.  The enforcement
is checked on a hardware level.

>> In the book Rainbow's End (minor spoilers here) it's hinted that all
>> the users are running computers which have object capaiblity security
>> and are thus much more resilient to attacks, except that the bottom
>> most layer of the system is intentionally government compromised so
>> that all systems are effectively backdoored.  So, your sustem is
>> secure... except for the backdoor.
>
> … and *that* sounds like NSA’s SELinux again ;)

Heh :)

> Seriously, though, I’m not saying we should “simply” use SELinux to
> address this problem, but I think it can be one of the first stops on
> our road to better systems.
>
>> Anyway... the goal of this email was mostly just to try to get people
>> thinking about the direction we want to go long term.  Hope that's
>> useful/interesting even if it isn't an actual contribution of code
>> towards it ;)
>
> Code is often overrated.  I find it very important to discuss our
> visions of the future to know in what direction we have to move and how
> much effort we should make to get there in time.

Good point!  I feel better about my braindump then. ;)