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.
Is there a particular reason why we wouldn't want to be more specific
with the distro ifdefs?
Respectfully,
--Mike
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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.
>
> Is there a particular reason why we wouldn't want to be more specific
> with the distro ifdefs?
>
> Respectfully,
> --Mike
> _______________________________________________
> 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
iQGcBAEBCgAGBQJWcuzQAAoJENAR6kfG5xmcYGcL/3V0kK53j6JmKwviBix17hpw
dgWYJYcuIw8gWcdG+ClAmt+mspPoxo324lvLvBsYOLK2c3KD/O4gDtezr+snLE89
W/1pmZNW51Ved0muefZW892+aP6fYbYD9vjCXe19IlcQGiqXIZWad0J+qrlt2xbe
rvHXpOTZ+a6HI7Mqkqmc2Gp4NG1tx1YbrgdOX1mNb0O5o6FAl6a4d3HwcWbej9R6
KoOXm/EmzQB/JS68FxaCKJ8LgIrE4p0RhdXCXAoKNyGQSPpoMv6rpjJFUtkJPqcu
0+vkzUmIAPDXLhCQwGErRJ/Q/QHG14HLXB8/Xdj2y8zjHria2jKZl0iyI6gCl9/n
QYSEY84/+dH72ROS9MJZMA6XBUUQTkBD/f2kQ9bQUJDYJREtQpvPisIW4//6Q3+G
jzhURFK/csiOHibLuw9UR7ELfM3jg7IhT4Gei8EBCF116Kgoz6KabDh30LZfgObF
Mqhk3P5UdM8diZNzqgz6br5mNWlfZkaGCya0EoOnJw==
=xOGX
-----END PGP SIGNATURE-----
On Thu, Dec 17, 2015 at 12:11 PM, Dominick Grift <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> 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.
This is also true; however, I was referring to items which are RH
specific. Correct me if I'm wrong but there is probably policy outside
of the systemd changes which differs between RHEL6 and RHEL7.
Thanks,
--Mike
>
>>
>> Is there a particular reason why we wouldn't want to be more specific
>> with the distro ifdefs?
>>
>> Respectfully,
>> --Mike
>> _______________________________________________
>> 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
>
> iQGcBAEBCgAGBQJWcuzQAAoJENAR6kfG5xmcYGcL/3V0kK53j6JmKwviBix17hpw
> dgWYJYcuIw8gWcdG+ClAmt+mspPoxo324lvLvBsYOLK2c3KD/O4gDtezr+snLE89
> W/1pmZNW51Ved0muefZW892+aP6fYbYD9vjCXe19IlcQGiqXIZWad0J+qrlt2xbe
> rvHXpOTZ+a6HI7Mqkqmc2Gp4NG1tx1YbrgdOX1mNb0O5o6FAl6a4d3HwcWbej9R6
> KoOXm/EmzQB/JS68FxaCKJ8LgIrE4p0RhdXCXAoKNyGQSPpoMv6rpjJFUtkJPqcu
> 0+vkzUmIAPDXLhCQwGErRJ/Q/QHG14HLXB8/Xdj2y8zjHria2jKZl0iyI6gCl9/n
> QYSEY84/+dH72ROS9MJZMA6XBUUQTkBD/f2kQ9bQUJDYJREtQpvPisIW4//6Q3+G
> jzhURFK/csiOHibLuw9UR7ELfM3jg7IhT4Gei8EBCF116Kgoz6KabDh30LZfgObF
> Mqhk3P5UdM8diZNzqgz6br5mNWlfZkaGCya0EoOnJw==
> =xOGX
> -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Thu, Dec 17, 2015 at 12:20:20PM -0500, Mike Palmiotto wrote:
> On Thu, Dec 17, 2015 at 12:11 PM, Dominick Grift <[email protected]> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > 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.
>
> This is also true; however, I was referring to items which are RH
> specific. Correct me if I'm wrong but there is probably policy outside
> of the systemd changes which differs between RHEL6 and RHEL7.
Maybe (would be good to have some examples) The question then is do
these changes warrant a new tunable
>
> Thanks,
> --Mike
>
> >
> >>
> >> Is there a particular reason why we wouldn't want to be more specific
> >> with the distro ifdefs?
> >>
> >> Respectfully,
> >> --Mike
> >> _______________________________________________
> >> 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
> >
> > iQGcBAEBCgAGBQJWcuzQAAoJENAR6kfG5xmcYGcL/3V0kK53j6JmKwviBix17hpw
> > dgWYJYcuIw8gWcdG+ClAmt+mspPoxo324lvLvBsYOLK2c3KD/O4gDtezr+snLE89
> > W/1pmZNW51Ved0muefZW892+aP6fYbYD9vjCXe19IlcQGiqXIZWad0J+qrlt2xbe
> > rvHXpOTZ+a6HI7Mqkqmc2Gp4NG1tx1YbrgdOX1mNb0O5o6FAl6a4d3HwcWbej9R6
> > KoOXm/EmzQB/JS68FxaCKJ8LgIrE4p0RhdXCXAoKNyGQSPpoMv6rpjJFUtkJPqcu
> > 0+vkzUmIAPDXLhCQwGErRJ/Q/QHG14HLXB8/Xdj2y8zjHria2jKZl0iyI6gCl9/n
> > QYSEY84/+dH72ROS9MJZMA6XBUUQTkBD/f2kQ9bQUJDYJREtQpvPisIW4//6Q3+G
> > jzhURFK/csiOHibLuw9UR7ELfM3jg7IhT4Gei8EBCF116Kgoz6KabDh30LZfgObF
> > Mqhk3P5UdM8diZNzqgz6br5mNWlfZkaGCya0EoOnJw==
> > =xOGX
> > -----END PGP SIGNATURE-----
> _______________________________________________
> 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
iQGcBAEBCgAGBQJWcu9KAAoJENAR6kfG5xmcRSsMALiwp5kt5oqAleIUgFPD8URk
ebi2AE1WSU6hHYu0ic8wFYcBRGAj189myFVLP1UwFee/M4kKeeg6uFgSzzcsNMwP
bza2b4uM80MOPL3Xktt0vMByLmJfbhBehEfUYZga9nl39vW/3HbEuyrvEo2NWjme
nxkQ71tU5Xc6PJgv4ryslHiqppnkZYPbeFMDoLZJNqng3G1ugcqLcD/Phfp079UN
sZ+ITS4KJpjuEf5XMNJis8ykqiEp414WD9wrCVOJtm01aD7swktfxqmMnmvc9zyK
fVuWCCj20Fy0CR/Q/pkSNZ4NCavqlcTnaSF/HQBcBQ8MJa14npn7ToPwqnWOqUQm
Akb+U/P/UIFFXzi7HNmLQ9x4eqO3nTgBl0cXMoxEfPtNGv8Qbi3RcbhteJa99jDB
3xjoZOXOj/q3vWxT5Tzmy4bauNJiyCNvaQja/tK5UyKQ2V3+UcIHHMKROCFvrKXv
aLwkHpxsXwes8hzu94YSfw4TZxnavSTDXevCS43cEw==
=87dP
-----END PGP SIGNATURE-----
On Thu, Dec 17, 2015 at 12:22 PM, Dominick Grift <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On Thu, Dec 17, 2015 at 12:20:20PM -0500, Mike Palmiotto wrote:
>> On Thu, Dec 17, 2015 at 12:11 PM, Dominick Grift <[email protected]> wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA512
>> >
>> > 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.
>>
>> This is also true; however, I was referring to items which are RH
>> specific. Correct me if I'm wrong but there is probably policy outside
>> of the systemd changes which differs between RHEL6 and RHEL7.
>
> Maybe (would be good to have some examples) The question then is do
> these changes warrant a new tunable
The issue actually arose while writing policy on top of RH's released
mls RPM (for two separate releases). It would be nice to be able to
write a single generic policy for applications which have undoubtedly
changed between major releases and have major-version-specific pieces
ifdefed (with the intent of eventually submitting these upstream). I
realize this isn't really a compelling enough argument for adoption,
so I'll see if I can dig up more concrete examples. Just thought I'd
give a bit more background behind the query.
--Mike
>
>>
>> Thanks,
>> --Mike
>>
>> >
>> >>
>> >> Is there a particular reason why we wouldn't want to be more specific
>> >> with the distro ifdefs?
>> >>
>> >> Respectfully,
>> >> --Mike
>> >> _______________________________________________
>> >> 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
>> >
>> > iQGcBAEBCgAGBQJWcuzQAAoJENAR6kfG5xmcYGcL/3V0kK53j6JmKwviBix17hpw
>> > dgWYJYcuIw8gWcdG+ClAmt+mspPoxo324lvLvBsYOLK2c3KD/O4gDtezr+snLE89
>> > W/1pmZNW51Ved0muefZW892+aP6fYbYD9vjCXe19IlcQGiqXIZWad0J+qrlt2xbe
>> > rvHXpOTZ+a6HI7Mqkqmc2Gp4NG1tx1YbrgdOX1mNb0O5o6FAl6a4d3HwcWbej9R6
>> > KoOXm/EmzQB/JS68FxaCKJ8LgIrE4p0RhdXCXAoKNyGQSPpoMv6rpjJFUtkJPqcu
>> > 0+vkzUmIAPDXLhCQwGErRJ/Q/QHG14HLXB8/Xdj2y8zjHria2jKZl0iyI6gCl9/n
>> > QYSEY84/+dH72ROS9MJZMA6XBUUQTkBD/f2kQ9bQUJDYJREtQpvPisIW4//6Q3+G
>> > jzhURFK/csiOHibLuw9UR7ELfM3jg7IhT4Gei8EBCF116Kgoz6KabDh30LZfgObF
>> > Mqhk3P5UdM8diZNzqgz6br5mNWlfZkaGCya0EoOnJw==
>> > =xOGX
>> > -----END PGP SIGNATURE-----
>> _______________________________________________
>> 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
>
> iQGcBAEBCgAGBQJWcu9KAAoJENAR6kfG5xmcRSsMALiwp5kt5oqAleIUgFPD8URk
> ebi2AE1WSU6hHYu0ic8wFYcBRGAj189myFVLP1UwFee/M4kKeeg6uFgSzzcsNMwP
> bza2b4uM80MOPL3Xktt0vMByLmJfbhBehEfUYZga9nl39vW/3HbEuyrvEo2NWjme
> nxkQ71tU5Xc6PJgv4ryslHiqppnkZYPbeFMDoLZJNqng3G1ugcqLcD/Phfp079UN
> sZ+ITS4KJpjuEf5XMNJis8ykqiEp414WD9wrCVOJtm01aD7swktfxqmMnmvc9zyK
> fVuWCCj20Fy0CR/Q/pkSNZ4NCavqlcTnaSF/HQBcBQ8MJa14npn7ToPwqnWOqUQm
> Akb+U/P/UIFFXzi7HNmLQ9x4eqO3nTgBl0cXMoxEfPtNGv8Qbi3RcbhteJa99jDB
> 3xjoZOXOj/q3vWxT5Tzmy4bauNJiyCNvaQja/tK5UyKQ2V3+UcIHHMKROCFvrKXv
> aLwkHpxsXwes8hzu94YSfw4TZxnavSTDXevCS43cEw==
> =87dP
> -----END PGP SIGNATURE-----
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.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Thu, Dec 17, 2015 at 1:52 PM, Christopher J. PeBenito
<[email protected]> 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
>
>
> --
> Chris PeBenito
> Tresys Technology, LLC
> http://www.tresys.com | oss.tresys.com
On 12/17/2015 3:26 PM, Mike Palmiotto wrote:
> On Thu, Dec 17, 2015 at 1:52 PM, Christopher J. PeBenito
> <[email protected]> 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
http://www.tresys.com | 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
> <[email protected]> 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
> > http://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-----
On Thu, Dec 17, 2015 at 3:51 PM, Christopher J. PeBenito
<[email protected]> wrote:
> On 12/17/2015 3:26 PM, Mike Palmiotto wrote:
>> On Thu, Dec 17, 2015 at 1:52 PM, Christopher J. PeBenito
>> <[email protected]> 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