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 1PbZUu-0004WX-1D for garchives@archives.gentoo.org; Sat, 08 Jan 2011 14:10:24 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 46531E06B0 for ; Sat, 8 Jan 2011 14:10:23 +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 9248FE0698 for ; Sat, 8 Jan 2011 13:45:57 +0000 (UTC) Received: by ewy6 with SMTP id 6so8068440ewy.40 for ; Sat, 08 Jan 2011 05:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=u0hvgf2P2/ypY+xGIkO8eVZEj5Nhhh1X9fewycMb/Sc=; b=pjevef9KD9xskeNSPufuUi1lXAKIRiIALgnBF0v4GuSOifrA2I/7C8ChBjjXVsVJJ2 pekqBz0Y63FtVnhLlFu2dNtQdDjhg5kxd/1zFyCimd39RgXZ2bIYXVkME0lC6AwQUlZE wKcVj8dOjxgd0jSywn3xaWexlp2ooDhLKB3pY= 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=Z52bv3Qx6SOAIWI2NYmAL9HVuV8lqvjrYds2yZL6uxy9g/xJdnYFx/7I37OgrU7lZ5 kB/v+dZ3wbeU/lCny0PLAjeShrKO+/pZnbP3hp1nhW9aMEdV+J8CkkgnwvUiWgklmLE3 kmhiw1nd8Gmt0G28LGvfuVjA01y1X1Q37PmkE= Received: by 10.213.33.206 with SMTP id i14mr10410130ebd.80.1294494356648; Sat, 08 Jan 2011 05:45:56 -0800 (PST) Received: from siphos.be ([83.101.67.57]) by mx.google.com with ESMTPS id b52sm3048484eei.19.2011.01.08.05.45.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 05:45:55 -0800 (PST) Sender: Sven Vermeulen Date: Sat, 8 Jan 2011 14:45:52 +0100 From: Sven Vermeulen To: gentoo-hardened@lists.gentoo.org Subject: [gentoo-hardened] SELinux ebuilds and patches Message-ID: <20110108134552.GA11521@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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 1e3e6614-f1b8-4655-841d-560832ec2340 X-Archives-Hash: 1ab70dadaf93fdd28839bf17914b9220 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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) - 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) - 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. 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) 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 --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk0oapAACgkQXfqz7M26L9tWrwCfeN60oIL7mjqrY+TTjuxQI6++ f4QAn35hWbl/79htAjb0NFFwwGcgZEOB =5BVe -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM--