From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Lemmer Webber Subject: Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support Date: Thu, 23 Aug 2018 09:43:13 -0400 Message-ID: <87bm9tryfi.fsf@dustycloud.org> References: <87d0u9s1x0.fsf@dustycloud.org> <87in41s0hl.fsf@elephly.net> 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]:48512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsptP-0003lf-6o for guix-devel@gnu.org; Thu, 23 Aug 2018 09:43:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsptL-0004qj-Pc for guix-devel@gnu.org; Thu, 23 Aug 2018 09:43:19 -0400 Received: from dustycloud.org ([50.116.34.160]:40466) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fsptL-0004pv-It for guix-devel@gnu.org; Thu, 23 Aug 2018 09:43:15 -0400 In-reply-to: <87in41s0hl.fsf@elephly.net> 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: Ricardo Wurmus Cc: guix-devel@gnu.org First off, I should mention that rain1 reminded me about OpenBSD's Capsicum and the Capsicum for Linux project, which I had mostly forgotten about: http://www.capsicum-linux.org/ Capsicum brings file descriptor based capabilities, and this is a reasonable intermediate approach. Shill is an ocap (object capability) supporting shell using Capsicum: http://shill.seas.harvard.edu/ Ricardo Wurmus writes: > 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 com= plicated 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.) I'm not a big fan of SELinux because it's using an RBAC style system, which is like a more fine grained ACL. It's still a centralized authority model, non-composable, and isn't as secure as a capability security type approach. I said this on IRC but: E in a Walnut has something to say about that > With tools like access control lists and firewalls, we engage = in "perimeter defense", which is more correctly described as "eggsh= ell defense". It is like an eggshell for the following reason: while= an eggshell may seem pretty tough when you tap on it, if you can ge= t a single pinhole anywhere in the surface, you can suck out the ent= ire yoke. Source: http://www.skyhunter.com/marcs/ewalnut.html My personal view is that ACL'ish / RBAC'ish systems are the wrong approach. I suppose if someone wants to put effort into this direction I don't object, unless it starts to complicate our tooling. But for focusing our efforts what I think we should do is work towards a better long-term security approach of supporting object capability operating system ideas. >> - 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 wit= h the > Hurd and Guix underpinnings. Unfortunately, Hurd is not considered a > priority by GNU, which shows in the lack of support for modern hardware. Yes, this is unfortunate. >> 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 microkerne= l + > ocap on top of proprietary hardware be *worse* than the current > situation of a monolithic ACL-based system on top of equally proprietary > hardware? The problem is that a much better implemented system will be harder to break out of. Right now many people "jailbreak" systems so they can install free software on them. We want to build watertight security systems so that when users *control their hardware*, the programs on their machines cannot do damage that they shouldn't be able to do. But if the same watertight security system was applied but the lowest capability layers were out of the user control, it might not be possible to break free. We can already see some of this today. My understanding of why Intel won't release a chip without ME, for instance, is that it's key to the DRM systems that enforce playback of blue-ray players. The enforcement is checked on a hardware level. >> 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 ;) Heh :) > 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. Good point! I feel better about my braindump then. ;)