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

[Ludovic Courtès]

Hi there!

Christopher Lemmer Webber <address@hidden> skribis:

>  - It's getting hard to trust our computers as in terms of our physical
>    hardware.  Companies like Purism are helping to build blobless
>    systems, but even then the hardware is built on un-auditable and
>    with growing apparent insecurity (Spectre, Meltdown) with little
>    chance of fixing things.  RISC-V has a libre instruction set, and in
>    the long term I think we want to support that.

Probably, though it’s hard to tell what RISC-V-based hardware will look
like—companies in a position to fabricate CPUs and to build computers
have goals not necessarily aligned with user freedom and autonomy.
RISC-V remains may be our best hope at this point, though.

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

Definitely!

>  - What paths do we have forward on that last one?
>
>    - 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.
>
>    - There's also seL4 which has a verified security kernel, possibly
>      even seL4 with Genode.  I'm not sure how hard it will be to run
>      POSIX type things on Genode.
>
>    - There's also Google's recent work with Magenta/Fuschia.  From what
>      I've read, architecturally this looks right.  I think the reason
>      for worry here is the same difficulty the community has had to
>      build actual community and libre distributions on top of the
>      Android ecosystem could apply here.

Indeed.

We could also mention MINIX, which many of us are already using daily.
:-)

Putting aside Fuschia, I think the Hurd and MINIX are by far the
solutions that require the less work to be in a state where people with
“regular needs” like the rest of us to switch (MINIX is probably in that
state already.)

The Hurd already has a very advanced POSIX C library, which is not
negligible, especially compared to the other OSes.  Much progress has
been made in recent years wrt. drivers (using the Rump kernel in
particular.)  There are of course serious shortcomings, in particular
lack of 64-bit and SMP support.  But fixing these is relatively “little
work” in the grand scheme of things.

To put this in perspective, consider Linux namespaces: they have already
seen years of evolution, and the story of user namespaces shows that
it’s far from complete.

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

Yeah.

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

Another option that we can already start working on is to implement
least-authority in GNU/Linux through namespaces, as was discussed at:

  https://lists.gnu.org/archive/html/help-guix/2018-01/msg00056.html

Specifically there are two things we can implement:

  1. A ‘guix run’ command along the lines of
     <https://lists.gnu.org/archive/html/help-guix/2018-01/msg00108.html>.

  2. A mechanism that would allow, say, ‘guix package -i PKG --pola’ to
     automatically add “least-authority wrappers” around the binaries of
     PKG, pretty much like ‘guix pack --relocatable’ does (see
     ‘wrapped-package’ in (guix scripts pack)).

Not as bullet-proof as what an ocap OS or something like Qubes can
achieve, but already be an improvement.

For some packages (hi, ghostscript!), we might even want to add a
least-authority wrapper by default.

Thoughts?

Ludo’.