From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QuW3O-00080b-K4 for garchives@archives.gentoo.org; Fri, 19 Aug 2011 20:52:37 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F0AB621C138; Fri, 19 Aug 2011 20:52:18 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 8489221C03D for ; Fri, 19 Aug 2011 20:51:49 +0000 (UTC) Received: by smtp.gentoo.org (Postfix, from userid 617) id D82451B4029; Fri, 19 Aug 2011 20:51:48 +0000 (UTC) Date: Fri, 19 Aug 2011 20:51:48 +0000 From: Sven Vermeulen To: gentoo-hardened@lists.gentoo.org Subject: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay Message-ID: <20110819205148.GA29497@gentoo.org> Mail-Followup-To: gentoo-hardened@gentoo.org Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-hardened@lists.gentoo.org Reply-to: gentoo-hardened@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Archives-Salt: X-Archives-Hash: 25caba7b6e91839bd921bedc9827a1a9 Hi guys, I have just pushed selinux-base-policy--2.20110726-r2 to the hardened-dev overlay. There are not that many changes in it (although "not many" is relative of course) but some were quite necessary to be pushed out already. The main reason why I do it now and not wait until I've fixed the other bugs that are still lingering, is because for -r3 I might need to make more in-depth changes on how we support init scripts within SELinux. More on that later... First of all, the small list in changes: - for all domains that we add ourselves (like gorg, pan, skype, mutt, ...) I didn't include the regular user support yet (stupid me), so that's fixed now - nagios diskcheck plugin issue is fixed - xfce4 file contexts are fixed - userdomains can now use syslog - portage has improved layman/emerge-webrsync support (you will need to "rlpkg layman portage" though) - improved mutt domain definition (help from upstream) - puppet fixes (a few of them) - zabbix correction on context and support remote mysql support - LDAPS support for nsswitch stuff - update on courier-imap file contexts There is also one change under the hood, which is the support for the patchbundles. Up until now, the patchbundle was applied as one big bundle (epatch ...tbz2) which made it difficult to debug patching issues. With r2, the patches are applied one by one, so a failure in a patch immediately gives a clear error in which patch (and where). It also shows the user the list of patches being applied now - for those that like to watch epatch work, that is ;-) A second change is that the patches are now not only per-file fixes, but structured in logical patchsets. These logical sets are a lot easier to send upstream (and also mark as "approved upstream") and should make the introduction of new upstream versions a lot easier to integrate (I had too much time wasted due to manual patch transformations between 20101213 and 20110726). BTW, we currently have 50 patchsets applied, 2 of them have been accepted upstream (so we do not need to maintain those the moment a new refpolicy is released), 7 of them are pending, the rest I still need to submit (but first need to confirm that the issues have been resolved correctly). Okay, but what is this "in-depth" change that I was talking about. Well, SELinux policies support labeled init scripts. For instance, "slapd_initrc_exec_t" which allows the init script to run in an init script domain specific for slapd (splad_initrc_t). This allows for slapd-specific allow statements (for instance PID file management) from within the init script. All fine, but Gentoo doesn't use that. We run all our scripts in initrc_t instead. Why? Because we support "integrated run_init support", which allows our users to just call "/etc/init.d/slapd start" instead of "run_init /etc/init.d/slapd start". But this integrated run_init support automatically transitions all scripts to initrc_t (and not slapd_initrc_t). And changing this to support the named init scripts isn't straight forward (well, I hope I eventually find a straight-forward method, but until now I didn't succeed). Yet we will eventually need to support this, because otherwise we need to "open" the privileges on initrc_t towards all potential services. Not only does that require lots of work, it also brings in patches in our policy that upstream will never accept (and they're right not to accept it). Hence I'll be working on that the upcoming days. Wkr, Sven Vermeulen