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

[Ricardo Wurmus]

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.)

>    - 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.

> 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?

> 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 ;)

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.

--
Ricardo