From owner-freebsd-security@FreeBSD.ORG Tue Feb 11 10:35:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07C6FD37 for ; Tue, 11 Feb 2014 10:35:56 +0000 (UTC) Received: from cu01176a.smtpx.saremail.com (cu01176a.smtpx.saremail.com [195.16.150.151]) by mx1.freebsd.org (Postfix) with ESMTP id BA64E1200 for ; Tue, 11 Feb 2014 10:35:55 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id 906D59DD003 for ; Tue, 11 Feb 2014 11:28:23 +0100 (CET) From: Borja Marcos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Proposal: tunable default/init label for MAC policies Date: Tue, 11 Feb 2014 11:28:22 +0100 Message-Id: <5C244CC2-A0D5-43B9-BA30-6B54E02F1C0F@sarenet.es> To: freebsd-security@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 10:35:56 -0000 (I've just sent this to trustedbsd-discuss but the list is probably = dead, so I am crossposting) Hello, I am using a combination of mac_biba, mac_mls and mac_bsdextended to = secure a shared hosting web server. The goals of each policy are: - mac_biba: Protect the integrity of the OS and configuration files = against actions derived of a security breach of a user's website. = Example, the typical PHP crap. Any descendant of a user process should = be unable to modify anything but the files in that user's directory. - mac_mls: Protect certain sensible files against read access by = descendants of user processes. For example, we wish to protect key = system files from Apache and its descendants, and Apache configuration = files themselves from PHP/CGI processes or, of course, their = descendants. - mac_bsdextended so that users whose uid falls inside the "hosting = users" set, imagine, 10000-20000, can't see processes or files belonging = to other uids within that set. The intent is to minimize surprise (hence, no need for a lot of = technical support to adapt crappy CGI/PHP code for security = requirements) but, at the same time, keeping good security measures. This scheme has been used for years with very good results, without the = mls policy, but we have stumbled upon an obstacle with MLS. The mls = module defines a default mls label of mls/low, which gets applied to = processes that haven't been spawned after a setusercontext() call. So, = for example, applying a mls/high label to the ssh private keys makes = sshd inoperable, as it's launched by init, and gets a mls/low label, = unable to read its private keys. A tunable like security.mac.{mls,biba...}.default_label or, maybe, more = appropiately, security.{mac,biba...}.init_lable would allow the = administrator to, for example, limit the usage of the MAC policies to = descendants of certain processes. In our case, with most of the OS = having the usual Unix security requirements, except for the intrinsicly = dangerous stuff such as Apache and PHP/CGIs, init labels of = {mls,biba}/equal would be more than enough, applying the necessary = labels to the untrusted processes. What do you think? I am sure this makes the MAC policies much more = useful, and much easier to integrate with the typical Unix software = without unnecessary incompatibilities, and of course not just for our = particular scenario. Borja.