From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support Date: Thu, 23 Aug 2018 14:58:46 +0200 Message-ID: <87in41s0hl.fsf@elephly.net> 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]:36354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fspHz-0001K0-Fz for guix-devel@gnu.org; Thu, 23 Aug 2018 09:04:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fspCe-00015Z-D2 for guix-devel@gnu.org; Thu, 23 Aug 2018 08:59:11 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21057) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fspCe-000144-5q for guix-devel@gnu.org; Thu, 23 Aug 2018 08:59:08 -0400 In-reply-to: <87d0u9s1x0.fsf@dustycloud.org> 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 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=E2=80=99t pretty, but it isn=E2=80=99t quite as compl= icated 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=E2=80=99d 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=E2=80=99t 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. =E2=80=A6 and *that* sounds like NSA=E2=80=99s SELinux again ;) Seriously, though, I=E2=80=99m not saying we should =E2=80=9Csimply=E2=80= =9D 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