From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support Date: Mon, 24 Sep 2018 16:14:32 +0200 Message-ID: <87bm8nugmv.fsf@inria.fr> References: <87d0u9s1x0.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g4RdI-000354-3Q for guix-devel@gnu.org; Mon, 24 Sep 2018 10:14:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g4RdE-0005LU-G1 for guix-devel@gnu.org; Mon, 24 Sep 2018 10:14:40 -0400 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Christopher Lemmer Webber Cc: guix-devel@gnu.org Hi there! Christopher Lemmer Webber 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=E2=80=99s hard to tell what RISC-V-based hardware will = look like=E2=80=94companies in a position to fabricate CPUs and to build compute= rs 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 =E2=80=9Cregular needs=E2=80=9D like the rest of us to switch (MINIX is pro= bably 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 =E2=80=9Cli= ttle work=E2=80=9D 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=E2=80=99s 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 =E2=80=98guix run=E2=80=99 command along the lines of . 2. A mechanism that would allow, say, =E2=80=98guix package -i PKG --pola= =E2=80=99 to automatically add =E2=80=9Cleast-authority wrappers=E2=80=9D around th= e binaries of PKG, pretty much like =E2=80=98guix pack --relocatable=E2=80=99 does (= see =E2=80=98wrapped-package=E2=80=99 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=E2=80=99.