[refpolicy] Use of distro_rhel6/7 in refpolicy

[cpebenito@tresys.com (Christopher J. PeBenito)]

On 12/17/2015 3:26 PM, Mike Palmiotto wrote:
> On Thu, Dec 17, 2015 at 1:52 PM, Christopher J. PeBenito
> <cpebenito@tresys.com> 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.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com