From: mike.palmiotto@crunchydata.com (Mike Palmiotto) Date: Thu, 17 Dec 2015 16:52:05 -0500 Subject: [refpolicy] Use of distro_rhel6/7 in refpolicy In-Reply-To: <56732065.20207@tresys.com> References: <20151217171148.GA26674@x250> <5673046D.7030404@tresys.com> <56732065.20207@tresys.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Thu, Dec 17, 2015 at 3:51 PM, Christopher J. PeBenito wrote: > On 12/17/2015 3:26 PM, 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. > > Changing object classes is uncommon, and usually they're only added. > > I'd certainly prefer to keep the least amount of policy running on any > particular system, but it's not practical from the general refpolicy > perspective. Reducing refpolicy is best done when one is implementing a > policy for a specific system. So unless an object class change > unnecessarily causes a huge amount (at least several hundred, if not > thousands) of rules, it isn't compelling enough to warrant a distro option. So it would seem that (outside of file context changes), most of the changes between major versions can typically be handled by tweaking which modules are loaded on a system. Thanks for entertaining the discussion. I guess we'll just have to cross this bridge if/when we get there. --Mike