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 521B7138D17 for ; Mon, 13 Jul 2015 16:50:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E9041E08F8; Mon, 13 Jul 2015 16:50:10 +0000 (UTC) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3C4F6E08E8 for ; Mon, 13 Jul 2015 16:50:10 +0000 (UTC) Received: by oihq81 with SMTP id q81so44420416oih.2 for ; Mon, 13 Jul 2015 09:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=tZDd/jFLIIKmERaZM1E+elAgAlDXX7o+ndL0SDUC8zo=; b=btEh5K1uBLt3yTBKkgfnbgSTsx+fzPHAtIi3jzglyS19IkYXfsciV/bfYVJL5dLy/8 Buxi9LI78PBPAo+lYaQKjFasjqVdztMfIIVnTSXbgB8Kain9wPpPDyYCwM6ai+Gg94d6 J/5iLyEJBBBGKiypH9XhSlHSGkmOnR2TJ7hh3W5nRrSMY6bCl08JVAJ4ed6cvzzwcYlJ mujLTxWMJlYZV0CqBdwWfnPR+LTwyeAWnYdD6boTyInDfXuV7g2z5trzLA27mUjeUcNL bqw+5ChKtciEfejYxXEqWkTzb6Wd6yYozKYw0E/Gu4/K40iAMXGxg+4y+UHe2kH0xibY cOmQ== 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 X-Received: by 10.202.86.215 with SMTP id k206mr29503598oib.13.1436806209484; Mon, 13 Jul 2015 09:50:09 -0700 (PDT) Sender: sven.j.vermeulen@gmail.com Received: by 10.202.217.5 with HTTP; Mon, 13 Jul 2015 09:50:09 -0700 (PDT) In-Reply-To: <20150713135151.GA21722@meriadoc.Home> References: <20150712234603.GQ2951@dent.vctlabs.com> <20150713113133.GA17362@meriadoc.Home> <20150713135151.GA21722@meriadoc.Home> Date: Mon, 13 Jul 2015 18:50:09 +0200 X-Google-Sender-Auth: JLSPZfR4PP2_OwgydnWqTyYCr7I Message-ID: Subject: Re: [gentoo-hardened] Feedback on article recommending Gentoo for SELinux From: Sven Vermeulen To: gentoo-hardened@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 95da7edf-3211-41a4-8cb8-0d2592639f02 X-Archives-Hash: 8e160e421c54b0b6141c8bea638d8130 On Mon, Jul 13, 2015 at 3:51 PM, Jason Zaman wrote: > On Mon, Jul 13, 2015 at 03:02:55PM +0200, Sven Vermeulen wrote: >> On Mon, Jul 13, 2015 at 1:31 PM, Jason Zaman wrote: >> > Secondly, related to "poor support for preserving local changes across >> > system updates". The tools now have the concept of priority so users can >> > easy completely replace a distro-provided module at a higher priority >> > (semodule -X 900 -i foo.pp). I haven't (yet) updated our selinux eclass >> > to install at a lower priority but will hopefully do that soon. >> >> We work with the default 400 (100 is for the migrated modules). Do you >> see a reason why we have to explicitly support a particular priority >> in our eclass? > > Hmm. I thought the point of the priorities was that things the user has > done should be separate from what the distro provides. Either the distro > uses 400 and any overrides the user does in a higher level or we change > the eclass to use a lower level and the user gets the default. That way > its easier for the user to see what customizations have been made. > > I was going to make a patch first then discuss but the basic idea was to > semodule -X 100 -i $MOD.pp then remove the module from level 400 > afterwards if it exists. Thoughts? And if we do, do we want to use level > 100? 200? I think that it is sufficient to inform users that they can override modules by picking a level higher than 400. If we would use a lower value ourselves, we should've done that before the 2.4 migration went stable and with sufficient documentation support. And I'm personally not convinced we should go that route anyway. If we implement logic right now, then how would we make sure that this logic is only executed once? You'd need to hack some logic in the (already somewhat complex) eclass to only do this once (if successfull). And to what benefit? The priority stuff is nice, but I find that it is somewhat a feature that was implemented "because it was easy" and not because it is well thought through (sorry for whomever implemented it - nothing personal). Policy developers and users who do some policy enhancements (which is the scope of the exercise we're talking about) who want to overrule an existing policy will want to still benefit from evolutions in the interfaces that they call. But that isn't the case, because interface updates require rebuilds of the policy (CIL *might* remove this obstacle depending on the implementation). In other words, if I overrule the xserver module with my own, and the init_daemon_domain() interface is updated, then this update will not be taken into account. Whereas within Gentoo, we do a full policy update (revbump) to make sure that updates on the interfaces are taken up. The priority stuff makes more sense in a managed environment, for instance where you do policy "upgrades" and validate if things still work properly. If they don't, unload them again, otherwise unload the previous versions of the modules. But this needs to be managed and supported. Right now, I'm guessing 95% of our users still have their old policy in the 100-range. Remember the kdevtmpfs related patch I once suggested to the eclass? [1] Its horrible code, and this one didn't have to deal with "just doing this once". [1] https://archives.gentoo.org/gentoo-hardened/message/08b8c81d79720857045d762bb8cdbf62 I think we should put our focus elsewhere. Module priorities are nice, but are not the innovative solution that our users are waiting for. Unlike some of the CIL promises that we still need to see land ;-) Wkr, Sven Vermeulen