From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E823B13800E for ; Thu, 26 Jul 2012 12:02:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C9D54E077B for ; Thu, 26 Jul 2012 12:02:58 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D13E921C010 for ; Thu, 26 Jul 2012 09:40:30 +0000 (UTC) Received: by smtp.gentoo.org (Postfix, from userid 617) id 359511B4510; Thu, 26 Jul 2012 09:40:30 +0000 (UTC) Date: Thu, 26 Jul 2012 09:40:30 +0000 From: Sven Vermeulen To: gentoo-project@lists.gentoo.org Subject: [gentoo-project] Faster stabilization of SELinux policies Message-ID: <20120726094030.GA27529@gentoo.org> Mail-Followup-To: gentoo-project@gentoo.org Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 745c5641-763d-4698-84f3-cfc99e428dfa X-Archives-Hash: c6052d0c323e5a5021beed82a3bf1c7c I'm hoping this is sufficiently "non-technical" to be on -project ;-) SELinux uses a "deny all by default" principle, which means that anything that isn't explicitly allowed is denied. When a policy (i.e. the rules that the system and its processes need to adhere to) is updated, it usually is enhanced (more rights added) rather than reduced (rights removed). This is mainly because it is hard to find out which rules can be removed without risk of introducing regressions. When things change on a system (we've had a few in the near past, think about udev binary move, /run introduction, /usr merge, ...) the policies almost always need to be changed. Sadly, these changes are often faster brought into the stable tree than I can detect. I try to reduce the likelihood of this with more automated infrastructural tests and autobuilds, but things do fall through (for instance, /run issues only coming up when /var/run is a symlink, which isn't the case for "older" installations). To still support stable users, I currently use the "standard" 30-day stabilization period for the policies, but when I know the "pending stable" policy has other issues (it fixes /run, but now also needs the udev-binary move) I start the 30-day counter on the next policy. As a result, stable users are often "forced" to use ~arch policies. I would like to use a 14-day stabilization period instead. Why shorter? Well, first of all, there is already a period of testing within the hardened-dev overlay. Also, as policies are usually updated (enhanced) the risk of introducing regressions (in the policy that is) is low. Finally, it'll allow stable users to get their needed updates. There will be policy changes for which I'll use a 30-day period. For instance, when core system confined domains are rewritten (or split) or when some rights have been removed. This is also why I rather not have all users always use ~arch because there will be times that the policies get more thorough changes. This has been discussed on the last hardened meeting where everyone agreed on, and I'm hoping I can get your support for this as well. Wkr, Sven Vermeulen