* [refpolicy] Use of distro_rhel6/7 in refpolicy @ 2015-12-17 17:00 Mike Palmiotto 2015-12-17 17:11 ` Dominick Grift 0 siblings, 1 reply; 10+ messages in thread From: Mike Palmiotto @ 2015-12-17 17:00 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Use of distro_rhel6/7 in refpolicy 2015-12-17 17:00 [refpolicy] Use of distro_rhel6/7 in refpolicy Mike Palmiotto @ 2015-12-17 17:11 ` Dominick Grift 2015-12-17 17:20 ` Mike Palmiotto 2015-12-17 18:52 ` Christopher J. PeBenito 0 siblings, 2 replies; 10+ messages in thread From: Dominick Grift @ 2015-12-17 17:11 UTC (permalink / raw) To: refpolicy -----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----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Use of distro_rhel6/7 in refpolicy 2015-12-17 17:11 ` Dominick Grift @ 2015-12-17 17:20 ` Mike Palmiotto 2015-12-17 17:22 ` Dominick Grift 2015-12-17 18:52 ` Christopher J. PeBenito 1 sibling, 1 reply; 10+ messages in thread From: Mike Palmiotto @ 2015-12-17 17:20 UTC (permalink / raw) To: refpolicy On Thu, Dec 17, 2015 at 12:11 PM, Dominick Grift <dac.override@gmail.com> 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----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Use of distro_rhel6/7 in refpolicy 2015-12-17 17:20 ` Mike Palmiotto @ 2015-12-17 17:22 ` Dominick Grift 2015-12-17 17:41 ` Mike Palmiotto 0 siblings, 1 reply; 10+ messages in thread From: Dominick Grift @ 2015-12-17 17:22 UTC (permalink / raw) To: refpolicy -----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 <dac.override@gmail.com> 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----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Use of distro_rhel6/7 in refpolicy 2015-12-17 17:22 ` Dominick Grift @ 2015-12-17 17:41 ` Mike Palmiotto 0 siblings, 0 replies; 10+ messages in thread From: Mike Palmiotto @ 2015-12-17 17:41 UTC (permalink / raw) To: refpolicy On Thu, Dec 17, 2015 at 12:22 PM, Dominick Grift <dac.override@gmail.com> 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 <dac.override@gmail.com> 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----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Use of distro_rhel6/7 in refpolicy 2015-12-17 17:11 ` Dominick Grift 2015-12-17 17:20 ` Mike Palmiotto @ 2015-12-17 18:52 ` Christopher J. PeBenito 2015-12-17 20:26 ` Mike Palmiotto 1 sibling, 1 reply; 10+ messages in thread From: Christopher J. PeBenito @ 2015-12-17 18:52 UTC (permalink / raw) To: refpolicy 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 www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Use of distro_rhel6/7 in refpolicy 2015-12-17 18:52 ` Christopher J. PeBenito @ 2015-12-17 20:26 ` Mike Palmiotto 2015-12-17 20:51 ` Christopher J. PeBenito 2015-12-17 20:56 ` Dominick Grift 0 siblings, 2 replies; 10+ messages in thread From: Mike Palmiotto @ 2015-12-17 20:26 UTC (permalink / raw) To: refpolicy 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. Thoughts? --Mike [1] https://github.com/TresysTechnology/refpolicy/commit/58b302957652322288618ceda0771d39e74a9e46 > > > -- > Chris PeBenito > Tresys Technology, LLC > www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Use of distro_rhel6/7 in refpolicy 2015-12-17 20:26 ` Mike Palmiotto @ 2015-12-17 20:51 ` Christopher J. PeBenito 2015-12-17 21:52 ` Mike Palmiotto 2015-12-17 20:56 ` Dominick Grift 1 sibling, 1 reply; 10+ messages in thread From: Christopher J. PeBenito @ 2015-12-17 20:51 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Use of distro_rhel6/7 in refpolicy 2015-12-17 20:51 ` Christopher J. PeBenito @ 2015-12-17 21:52 ` Mike Palmiotto 0 siblings, 0 replies; 10+ messages in thread From: Mike Palmiotto @ 2015-12-17 21:52 UTC (permalink / raw) To: refpolicy On Thu, Dec 17, 2015 at 3:51 PM, Christopher J. PeBenito <cpebenito@tresys.com> wrote: > 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. 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Use of distro_rhel6/7 in refpolicy 2015-12-17 20:26 ` Mike Palmiotto 2015-12-17 20:51 ` Christopher J. PeBenito @ 2015-12-17 20:56 ` Dominick Grift 1 sibling, 0 replies; 10+ messages in thread From: Dominick Grift @ 2015-12-17 20:56 UTC (permalink / raw) To: refpolicy -----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 > <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. > > 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----- ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-12-17 21:52 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-12-17 17:00 [refpolicy] Use of distro_rhel6/7 in refpolicy Mike Palmiotto 2015-12-17 17:11 ` Dominick Grift 2015-12-17 17:20 ` Mike Palmiotto 2015-12-17 17:22 ` Dominick Grift 2015-12-17 17:41 ` Mike Palmiotto 2015-12-17 18:52 ` Christopher J. PeBenito 2015-12-17 20:26 ` Mike Palmiotto 2015-12-17 20:51 ` Christopher J. PeBenito 2015-12-17 21:52 ` Mike Palmiotto 2015-12-17 20:56 ` Dominick Grift
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.