From owner-freebsd-arch@FreeBSD.ORG Sun Jan 23 15:56:14 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48BAB106564A; Sun, 23 Jan 2011 15:56:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 211D68FC19; Sun, 23 Jan 2011 15:56:14 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B9B3D46B09; Sun, 23 Jan 2011 10:56:13 -0500 (EST) Date: Sun, 23 Jan 2011 15:56:13 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: Capsicum -- 9.x merge in sight X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 15:56:14 -0000 On Sun, 23 Jan 2011, Ivan Voras wrote: >> As many of you will now have heard, the Computer Laboratory at the >> University of Cambridge and Google have been collaborating for the last few >> years on a security research project called Capsicum. It consists of a set >> of extensions to the POSIX API adding a new "capability mode", >> "capabilities", "process descriptors", and several other additions required >> to implement a capability-oriented sandbox model in UNIX. These > > Hello, > > How is Capsicum positioned, from user & admin perspective, when compared to > the MAC work on FreeBSD and SELinux on Linux? Is one the superset of > another, will one obsolete another? This is a point addressed in some detail in the paper, which considers the relationship between Capsicum and other security models. Capsicum is really addressed at the application author, whereas MAC models are typically addressed at a blend of system integrators and system administrators. As a result, users mostly benefit from Capcisum transparently. We argue that Capsicum complements other security techniques, such as MAC, DAC, etc, which serve different roles in system design. As a result, Capsicum should be entirely transparent to end users -- except that vulnerabilities in applications become less critical -- which is quite different from what you see in various MAC models, including the TE model shipped with SELinux. >> The current plan is *not* to merge libcapsicum, a userspace library used by >> certain applications to construct sandboxes, as we feel the API remains >> insufficiently mature at this point. > > I vaguely remember that the MAC work has never gotten as popular on FreeBSD > as SELinux on Linux because it lacked user-oriented tools and documentation > - is there a danger Capsicum will end up the same? There's a long philosophical discussion to have on this topic, but suffice to say that the success or failure of Capsicum will depend on its adoption by application writers. The starting point for applications is our own application suite: the tools, daemons, etc, in our own operating system, and it seems we have a lot of interest in our community in taking that task up. In as much as we can convince other OS authors that Capsicum is a good idea, and that they should adopt it, that will help a great deal. Discussions in the Chromium, NetBSD, etc, communities are promising in this sense, but a lot more has to be done. One of the hardest problems in this area is one that Capsicum makes accessible, but doesn't solve: how to improve programmability for compartmentalisation and privielge separation. Today, that programmability problem is significant, but there are also quite a few interested parties working on it, and also existing components that use compartmentalisation -- Chromium being one of them, and hence a good case study since it allows us to compare different models from a programmer perspective. If you haven't yet read the paper, please do so, as I think it will help answer some of these questions. You may remember, BTW, that while I was at NAI Labs, we had a project to port the SELinux FLASK/TE parts to FreeBSD, and for a period, shipped an "sebsd.ko" kernel module implementing it using FreeBSD's MAC Framework. We saw very little interest from the community, and part of the reason for that is that it's actually extremely difficult to use outside of narrow appliance-like environments (for which TE was originally designed). It turns out that TE is used with FreeBSD, however: McAfee's Sidewinder firewall (the origins of the TE implementation in SELinux began life at SCC, who were bought by McAfee a couple of years ago), and also the Kylin operating system, which actually does use our SEBSD work. If there's interest in updating SEBSD, the pieces are all in Perforce, and over the years, the MAC Framework has evolved in several ways that would make that easier. However, even in the Linux community, SELinux is considered fairly controversial and quite difficult to use. And, to be far, MAC is actually extensively used by FreeBSD consumers. You'll find the MAC Framework in use to host policies in many downstream products: Mac OS X, iPhoneOS (now iOS), Junos, McAfee's Sidewinder, nCircle's products, and so on. The thing that has made MAC most hard to deploy (and why Apple has found it easier to deploy) actually has to do with the weakness of semantics of path names in UNIX -- something that's a bit different in Mac OS X. That same weakness has made SELinux hard to deploy: you can't efficiently, effectively, and safely use path names for implicit security labelling, meaning that you end up having to manage security labels on objects. (There's some interesting literature on this, see DTE vs. TE). This same concern has hurt the effectiveness of auditing as well. But it's hard to fix: many UNIX file system concepts (hard links, flexible mounting model, files without names, etc) are embedded in the structures of critical applications. Robert