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 1QFAjB-0004Jt-97 for garchives@archives.gentoo.org; Wed, 27 Apr 2011 19:48:49 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 67FF81C023; Wed, 27 Apr 2011 19:46:33 +0000 (UTC) Received: from mail-ew0-f53.google.com (mail-ew0-f53.google.com [209.85.215.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 131D11C023 for ; Wed, 27 Apr 2011 19:46:32 +0000 (UTC) Received: by ewy8 with SMTP id 8so761732ewy.40 for ; Wed, 27 Apr 2011 12:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:subject:message-id :mime-version:content-type:content-disposition:user-agent; bh=IPgE7E/oIxCQI1S23WeJdwY0wpw4xdASe15Oy31ryfI=; b=JkmeaSUkBM/MGQLR2PocG09rTJerXWPHh4v2lh0ksIf0fy7w9+xnKhRBv/u+NRsLWZ 5KKKjsyCviUFmPhC8XN4A5+HqyV9xkFYiNvo5AXsTqTMkdLcdhuvKY0aBz5aIM0p1KuJ iukWjmVQ4P+VKl2mDdARWftpJ8ZDWF42HX0Mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=WBp91vOjzmiBxXmW1fjW4ueUF5Zh20w3vIkdyRDy9ftD4b+3ZwWbUUmsAklAcCgsyF mc2Fx62AovThjPEUgvoxA5j3QG9B2HpjYxFvubsMXNp915YYyBpYeyr1nkA3IhisCXWm DLgTd1vve/30BUarUhPVYEPTfFh3D1VOIwfH8= Received: by 10.14.10.73 with SMTP id 49mr1119471eeu.24.1303933592190; Wed, 27 Apr 2011 12:46:32 -0700 (PDT) Received: from siphos.be ([83.101.67.57]) by mx.google.com with ESMTPS id s49sm766008eei.12.2011.04.27.12.46.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2011 12:46:31 -0700 (PDT) Sender: Sven Vermeulen Date: Wed, 27 Apr 2011 21:46:50 +0200 From: Sven Vermeulen To: gentoo-hardened@lists.gentoo.org Subject: [gentoo-hardened] SELinux Gentoo profiles (the /usr/portage/profiles kind) Message-ID: <20110427194650.GA23731@siphos.be> 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=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: X-Archives-Hash: f4d3247de1a2362f50e200fd03434688 Hi guys 'n gals, Like I suggested in the "SELinux and no-multilib" thread [1], I would like to take a stab at the SELinux Gentoo profiles to make them easy to manage (and to get that weird (no)multilib thing back on track). As the thread said, I am focussing on creating a "features/selinux" profile which, like the "features/multilib" or "features/no-nptl" ones, cannot be used directly but is used by a parent file within a profile. When a good "features/selinux" profile is created, we can then create hardened/linux/amd64/selinux hardened/linux/amd64/no-multilib/selinux hardened/linux/x86/selinux ... profiles in which only a single file exists, namely "parent", with the contents of ../ ../../../../features/selinux To verify that this is indeed possible, I've already started with a "features/selinux" profile on my own overlay [2] and am currently testing it (both a "hardened/linux/amd64/selinux" and ..."amd64/no-multilib/selinux" guest) to see if they generate any issues. Until now, I have not found any issue. What I do find is that the hardened/linux/amd64/* ones are more aligned with the hardened profiles than the selinux/v2refpolicy/amd64/hardened profile (current production-use profile) with respect to USE changes and such. In my opinion, this method has many advantages: - the selinux profiles are close to their master profile (and as such inherit the updates and management of those profiles) - the new profiles can be used simultaneously with the old ones, allowing for a transition period - the SELinux specific changes are tied in a single location, making administration a bit more easy (and we're all for easy, aren't we?) - if new profiles would like to support a selinux-specific one as well, it is far easier with a "features/selinux" approach than it is with the current selinux/v2refpolicy/* I think Now my question(s): - Does anyone know of a problem with this approach? - Does anyone have any objections if I (or someone else) puts this information in hardened-dev.git (blueness, you did last profile updates with a staging in hardened-dev.git, but in a separate branch [3], do you think this approach is needed here as well or can this be put in the master)? - And if people have objections, any other ideas on how to tackle the problem that current SELinux profiles do not support no-multilib (but do not enable "multilib" USE flag) [4]? Wkr, Sven Vermeulen [1] http://thread.gmane.org/gmane.linux.gentoo.hardened/4820/focus=4824 [2] https://github.com/sjvermeu/gentoo.overlay/tree/master/profiles [3] https://bugs.gentoo.org/show_bug.cgi?id=344861 [4] https://bugs.gentoo.org/show_bug.cgi?id=298434 and https://bugs.gentoo.org/show_bug.cgi?id=346563