From: mike.palmiotto@crunchydata.com (Mike Palmiotto) Date: Thu, 17 Dec 2015 12:41:09 -0500 Subject: [refpolicy] Use of distro_rhel6/7 in refpolicy In-Reply-To: <20151217172224.GB26674@x250> References: <20151217171148.GA26674@x250> <20151217172224.GB26674@x250> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Thu, Dec 17, 2015 at 12:22 PM, Dominick Grift 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 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-----