From: dac.override@gmail.com (Dominick Grift) Date: Thu, 17 Dec 2015 21:56:57 +0100 Subject: [refpolicy] Use of distro_rhel6/7 in refpolicy In-Reply-To: References: <20151217171148.GA26674@x250> <5673046D.7030404@tresys.com> Message-ID: <20151217205656.GC26674@x250> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Dec 17, 2015 at 03:26:37PM -0500, Mike Palmiotto wrote: > On Thu, Dec 17, 2015 at 1:52 PM, Christopher J. PeBenito > wrote: > > On 12/17/2015 12:11 PM, Dominick Grift wrote: > >> On Thu, Dec 17, 2015 at 12:00:14PM -0500, Mike Palmiotto wrote: > >>> It appears that the major-version-specific redhat ifdefs were > >>> abandoned as of 6624f9cf7a3cdc3deb19ca680f559011a75e5e9f, in favor of > >>> generic distro names. Considering the fact that there are some major > >>> differences between RHEL6 and RHEL7, I wonder if it would be > >>> worthwhile to re-introduce major version numbers. It seems like > >>> current efforts have been using 'init_systemd,' but that doesn't seem > >>> appropriate for non-systemd policy. > >> > >> I suspect "init_systemd" is probably the most accurate identifier you > >> one can have in this case. > >> > >> systemd is not a RH specific technology even though it is heavily > >> influenced by RH. Thus using "distro_rhel7" to indicate systemd seems > >> like a bit of a stretch. > > > > Agreed. > > > > > >>> Is there a particular reason why we wouldn't want to be more specific > >>> with the distro ifdefs? > > > > There was a rhel4 distro build option in the past to restore some rules > > that were removed in newer distributions due to functional changes. I'm > > not opposed to versioned distro options but am reluctant to accept them > > unless their value is clear. > > So, if I'm not mistaken, the functional changes you refer to were > mainly for audit/syslog support. One thing that comes to mind as > *almost* analogous is the introduction of netlink socket classes in > kernel versions 4.2-rc1+. Though this is not a perfect parallel > (RHEL6/7 are still v2/3.*), it certainly illustrates the potential > benefit of adding tunables for legacy distribution support [1]. > > I'm sure there are more directly relevant examples (which I will > continue to look for), but in the meantime, I believe this example > loosely applies to my request for more specific distro ifdefs. > > Thoughts? > --Mike > > [1] https://github.com/TresysTechnology/refpolicy/commit/58b302957652322288618ceda0771d39e74a9e46 That is not redhat specific. But even then. That commit is backwards compatible. Note how calls to the old "netlink_socket" were left in untouched. So it works on older and newer kernels. Youll just get a few messages in dmesg about unknown classes but that is no problem. Strictly speaking no reason for a new tunable RHEL4 policy was monolithic only the differences since then are from a different magnitude > > > > > > > -- > > Chris PeBenito > > Tresys Technology, LLC > > www.tresys.com | oss.tresys.com > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy - -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCgAGBQJWcyGUAAoJENAR6kfG5xmcK74MAKIFkPwWuSGbE09vgEy8Q0FE b6Ot+E5HH4wDeQOxAHLXCcGaDL+UeEn/w4twMAfpsAUs4/ecVy5i80vvyZcG0hzq Li84feEdfsNh6D7wwxrDx6oUe1Ll4QDK8JhOrDO4M6gVSLmVNcRC2/Fzcr943c70 zOI+/mqL09e3D5JEPRwZb8ACLlsMpYuh8pF2vyqocdbfZjuBqCuwaVRerMneW5ad rG7KpK7Bu+n4zsxNpo6llLzPB0BnwWToV0wb6Us0emg5ZtIRwuRrS5A80wnMc8I3 dMlj4lFwNI443IyLr3tUM4poHNDsi4swJc6tKBn2D2w0rrHocFu+IzFO0vTIFzy7 ojAHTC6mkOdbmi9UyYtCZWCozhr7bH6XX+izTBeEy9THDKueImZH7Ol5D1M2NVhx kphCJQyeWFtXosQohSgY13AWDWvLo7fBO9TWyqIkGP88rC8zCHDvbiKpJw6JU5B/ gPdXtVJU/SLW4dfMX+4deJK2XcFwQPanZ4w8KC84nA== =sqj7 -----END PGP SIGNATURE-----