From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Lemmer Webber Subject: Long term plan for GuixSD security: microkernels, ocap, RISC-V support Date: Thu, 23 Aug 2018 08:27:55 -0400 Message-ID: <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]:52698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsoiV-0007HN-39 for guix-devel@gnu.org; Thu, 23 Aug 2018 08:28:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsoiT-0003sL-Mu for guix-devel@gnu.org; Thu, 23 Aug 2018 08:27:59 -0400 Received: from dustycloud.org ([2600:3c02::f03c:91ff:feae:cb51]:58100) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fsoiT-0003ry-H5 for guix-devel@gnu.org; Thu, 23 Aug 2018 08:27:57 -0400 Received: from jasmine (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id 66BB826653 for ; Thu, 23 Aug 2018 08:27:56 -0400 (EDT) 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: guix-devel@gnu.org Hello... reading over a few articles this morning: - Researchers Blame =E2=80=98Monolithic=E2=80=99 Linux Code Base for Criti= cal Vulnerabilities https://threatpost.com/researchers-blame-monolithic-linux-code-base-for-= critical-vulnerabilities/136785/ - Its associated paper: "The Jury Is In: Monolithic OS Design Is Flawed" http://ts.data61.csiro.au/publications/csiro_full_text/Biggs_LH_18.pdf - Brains behind seL4 secure microkernel begin RISC-V chip port https://www.theregister.co.uk/2018/04/23/risc_v_sel4_port/ I'm bringing this up because I want to plant the seed for some thinking and conversation: - 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. - 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. - 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. - It's also worth noting that the most common class of serious application / library vulnerabilities that we have to deal with is C / C++ memory management issues. I'm not saying we should embrace everything getting ported to Rust, but I do think it's important to note that we're finally seeing paths out of that nightmare. 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. 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 ;)