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 1PboMn-0000pP-8x for garchives@archives.gentoo.org; Sun, 09 Jan 2011 06:03:01 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 46177E0730 for ; Sun, 9 Jan 2011 06:03:00 +0000 (UTC) Received: from mail.aoaforums.com (www.aoaforums.com [174.123.188.106]) by pigeon.gentoo.org (Postfix) with ESMTP id 2B468E0799 for ; Sun, 9 Jan 2011 05:10:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.aoaforums.com (Postfix) with ESMTP id 6FF531217B for ; Sun, 9 Jan 2011 05:10:40 +0000 (GMT) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.aoaforums.com 6FF531217B DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=giz-works.com; s=20080229-giz-works-com; t=1294549840; bh=Sf9ybXG2a8TYXi+MrdGiS4HzO+c=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=eGL9Gi4D8cCcJHa7CU4YkqWarpluYnhhdPbw2uNDLmeldIMh6gzo7T8wgRv0HEH/y UhIRmi0+8xV5j/sAs8GLB7EBaLNdZR8HOnNm6aKaPduxC+rpAs+8SSDtyX4ub6cbWq 7Qi6881JlejvGpRhN9xuY8zuow7aQvBO5DkpPnfM= X-Virus-Scanned: amavisd-new at aoaforums.com Received: from mail.aoaforums.com ([127.0.0.1]) by localhost (aoaforums.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArpW2DcTioGm for ; Sun, 9 Jan 2011 05:10:36 +0000 (GMT) Received: from [10.0.0.17] (adsl-70-134-53-63.dsl.spfdmo.swbell.net [70.134.53.63]) by mail.aoaforums.com (Postfix) with ESMTPSA id 822FAC200D for ; Sun, 9 Jan 2011 05:10:36 +0000 (GMT) Message-ID: <4D29434B.1070707@giz-works.com> Date: Sat, 08 Jan 2011 23:10:35 -0600 From: Chris Richards User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 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 To: gentoo-hardened@lists.gentoo.org Subject: Re: [gentoo-hardened] SELinux ebuilds and patches References: <20110108134552.GA11521@siphos.be> In-Reply-To: <20110108134552.GA11521@siphos.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 9d22b10c-aba5-4454-8b33-895054e60b64 X-Archives-Hash: 9568444b883c6ef310321b335b297c34 On 01/08/2011 07:45 AM, Sven Vermeulen wrote: > Hi Chris& hardened development, > > The ebuilds within the hardened-dev overlay for the SELinux policies are > currently fully based upon the reference policy as released by Tresys. The > changes made beyond the reference policy are currently added as patches in the > files/ folder. However, as things progress, the number of patches is increasing > and will soon hit the 20k limit that Gentoo (and the QA team) sets for files > inside the files/ folder. > > Of course, the main idea is that we feed back those changes towards the > reference policy development itself (which is gradually done) but this will take > time and will not remove this situation. > > A few solutions are possible: > > - Put the patches as separate downloads (SRC_URI in the ebuild), in which case > we will need to combine the patches in "less frequent" releases. This is > entirely plausible and used by other ebuilds as well. It also allows for some > package stability (the patchbundle in SRC_URI is the master, subpatching is > still possible through the files/ folder) > I personally favor this approach. It allows us to stay close to the refpolicy, and should also help in making it easier to track when something in refpolicy obviates the need for a particular patch. > - Create intermediate releases based on our own repository of the policies and > modules (like Fedora and other distributions do). This makes development > easier, but maintenance becomes more difficult: you'll need to perform quality > testing before we can create ebuilds (or use snapshots and from time to time > stabilize a snapshot) and staying close with the reference policy itself might > be more challenging (although I've heard great things of git being able to do > such mergers, but have no experience with that myself) > I do this in my private git repo. merging with git can sometimes be a bit challenging, but then I'm not well versed in git either. The concern about quality testing before we create ebuilds is, I think, a wash. We need to do that regardless of our approach. After all, a bad patch is still a pretty serious problem. IMO, this option is best kept for private repos. > - Instead of patching existing modules, we can also create modules that > introduce the "patches" themselves. After all, most (if not all) patches are > about allowing more things or declaring more types/domains rather than > dismissing privileges that have been granted. > This is neat and sexy, but can potentially create a situation where we have loads of packages coming and going as we change patch sets, plus the user not being able to have a reasonably good idea of what packages are pulled in as deps. Not to mention the whole issue of changing deps. And if we make a single package called selinux-patches or something similar, then we are really back to the first option. Or am I misunderstanding? > The biggest patch user remains the selinux-base-policy ebuild as this needs to > be patched every time. Until now, I have not seen any other ebuild which might > get too many patches. > > Why selinux-base-policy? Well, this one needs to be patched every time > > - an interface is added to some domain (regardless if the user is using that > domain or not) as only the base policy manages the include files in > /usr/share/selinux/strict/include (or targeted/include). > - an additional module is added as this means that the regular roles and domains > (user_t, staff_t and sysadm_t + affiliated roles) need to be 'enhanced' with > support for these modules (new module for gorg -> gorg_role interface needs to > be defined and used by the various users) > Every selinux-* package has an in-built dependency on selinux-base-policy anway, so I don't really see this as a problem. > I don't know what you guys think? Chris, you especially ;-) My personal > preference goes to the patches themselves so that we do not drift away from the > reference policy and are forced to keep track of it. Also, when a new release is > made, we can look at the individual patches to see which still need to be > included and which not. > > Wkr, > Sven Vermeulen