In the freeIPA project we have our own SELinux policy. We support RHEL 5 up through Fedora Rawhide. With Fedora 11 we saw some problems compiling our SELinux module which Dan Walsh provided a patch for. I haven't tried this on older releases yet but I'm guessing it won't work as expected (some policies seem to have been renamed, such as corenet_non_ipsec_sendrecv() -> corenet_all_recvfrom_unlabeled()
My question is, how can we handle this in our source tree? Are we going to need to maintain per-release policies or does SELinux support some sort of versioning conditionals?
thanks
rob
On Tue, 2009-06-30 at 10:08 -0400, Rob Crittenden wrote:
In the freeIPA project we have our own SELinux policy. We support RHEL 5 up through Fedora Rawhide. With Fedora 11 we saw some problems compiling our SELinux module which Dan Walsh provided a patch for. I haven't tried this on older releases yet but I'm guessing it won't work as expected (some policies seem to have been renamed, such as corenet_non_ipsec_sendrecv() -> corenet_all_recvfrom_unlabeled()
My question is, how can we handle this in our source tree? Are we going to need to maintain per-release policies or does SELinux support some sort of versioning conditionals?
thanks
rob
There is tunable policy, meaning you can tune you policy for specific distros for example. You do this by building the policy with DISTRO=(distro). See the SELinux makefile:
http://oss.tresys.com/projects/refpolicy/browser/trunk/Makefile
starting at line 179: # enable distribution-specific policy
Then in the policy itself you would put the distro specifics into seperate blocks of policy. For example:
http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/servic...
starting at line 702: ifdef(`distro_redhat',` ')
Which is policy specific to RedHat distributions. So if you build with DISTRO=redhat this specific policy is added.
You may or may not be able to use this mechanism for you scenario.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On 06/30/2009 10:08 AM, Rob Crittenden wrote:
In the freeIPA project we have our own SELinux policy. We support RHEL 5 up through Fedora Rawhide. With Fedora 11 we saw some problems compiling our SELinux module which Dan Walsh provided a patch for. I haven't tried this on older releases yet but I'm guessing it won't work as expected (some policies seem to have been renamed, such as corenet_non_ipsec_sendrecv() -> corenet_all_recvfrom_unlabeled()
My question is, how can we handle this in our source tree? Are we going to need to maintain per-release policies or does SELinux support some sort of versioning conditionals?
thanks
rob
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
The old interface will work, it just reports a nasty warning message when you compile it against newer policy. So I think you are safe compiling it on RHEL5 and installing it on F10/F11.
Daniel J Walsh wrote:
On 06/30/2009 10:08 AM, Rob Crittenden wrote:
In the freeIPA project we have our own SELinux policy. We support RHEL 5 up through Fedora Rawhide. With Fedora 11 we saw some problems compiling our SELinux module which Dan Walsh provided a patch for. I haven't tried this on older releases yet but I'm guessing it won't work as expected (some policies seem to have been renamed, such as corenet_non_ipsec_sendrecv() -> corenet_all_recvfrom_unlabeled()
My question is, how can we handle this in our source tree? Are we going to need to maintain per-release policies or does SELinux support some sort of versioning conditionals?
thanks
rob
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
The old interface will work, it just reports a nasty warning message when you compile it against newer policy. So I think you are safe compiling it on RHEL5 and installing it on F10/F11.
We compile it on the given platform so we need some way to support all at once.
For example, the code that builds fine on F-11 fails like this on F-9:
Compiling targeted ipa_webgui module /usr/bin/checkmodule: loading policy configuration from tmp/ipa_webgui.tmp ipa_webgui.te":77:ERROR 'syntax error' at token 'userdom_dontaudit_search_admin_dir' on line 10764: userdom_dontaudit_search_admin_dir(ipa_webgui_t)
The diff between F-11 and F-9 being:
-userdom_dontaudit_search_sysadm_home_dirs(ipa_webgui_t) +userdom_dontaudit_search_admin_dir(ipa_webgui_t)
rob
On 06/30/2009 04:41 PM, Rob Crittenden wrote:
Daniel J Walsh wrote:
On 06/30/2009 10:08 AM, Rob Crittenden wrote:
In the freeIPA project we have our own SELinux policy. We support RHEL 5 up through Fedora Rawhide. With Fedora 11 we saw some problems compiling our SELinux module which Dan Walsh provided a patch for. I haven't tried this on older releases yet but I'm guessing it won't work as expected (some policies seem to have been renamed, such as corenet_non_ipsec_sendrecv() -> corenet_all_recvfrom_unlabeled()
My question is, how can we handle this in our source tree? Are we going to need to maintain per-release policies or does SELinux support some sort of versioning conditionals?
thanks
rob
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
The old interface will work, it just reports a nasty warning message when you compile it against newer policy. So I think you are safe compiling it on RHEL5 and installing it on F10/F11.
We compile it on the given platform so we need some way to support all at once.
For example, the code that builds fine on F-11 fails like this on F-9:
Compiling targeted ipa_webgui module /usr/bin/checkmodule: loading policy configuration from tmp/ipa_webgui.tmp ipa_webgui.te":77:ERROR 'syntax error' at token 'userdom_dontaudit_search_admin_dir' on line 10764: userdom_dontaudit_search_admin_dir(ipa_webgui_t)
The diff between F-11 and F-9 being:
-userdom_dontaudit_search_sysadm_home_dirs(ipa_webgui_t) +userdom_dontaudit_search_admin_dir(ipa_webgui_t)
rob
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
RIght I think you would need to build on F9 for support on F11 not the other way around. Just like you would do with shared libraries. You would not expect an c executable built on F11 to run on F9?
On Tue, 2009-06-30 at 17:28 -0400, Daniel J Walsh wrote:
RIght I think you would need to build on F9 for support on F11 not the other way around. Just like you would do with shared libraries. You would not expect an c executable built on F11 to run on F9?
I think he wants a single code base which can be built on F9 or F11. I might not expect that C to run, but I'd expect the same source could be compiled on either.
We aren't providing enough information for his policy to know which interface it should be using, not sure how to solve the problem, but obviously Rob want a way to use the new interface if it is there and to use the old interface if it is not.....
-Eric
Eric Paris wrote:
On Tue, 2009-06-30 at 17:28 -0400, Daniel J Walsh wrote:
RIght I think you would need to build on F9 for support on F11 not the other way around. Just like you would do with shared libraries. You would not expect an c executable built on F11 to run on F9?
I think he wants a single code base which can be built on F9 or F11. I might not expect that C to run, but I'd expect the same source could be compiled on either.
We aren't providing enough information for his policy to know which interface it should be using, not sure how to solve the problem, but obviously Rob want a way to use the new interface if it is there and to use the old interface if it is not.....
-Eric
Yes, this is exactly what I was trying to say.
rob
On Tue, 2009-06-30 at 21:46 -0400, Eric Paris wrote:
On Tue, 2009-06-30 at 17:28 -0400, Daniel J Walsh wrote:
RIght I think you would need to build on F9 for support on F11 not the other way around. Just like you would do with shared libraries. You would not expect an c executable built on F11 to run on F9?
I think he wants a single code base which can be built on F9 or F11. I might not expect that C to run, but I'd expect the same source could be compiled on either.
We aren't providing enough information for his policy to know which interface it should be using, not sure how to solve the problem, but obviously Rob want a way to use the new interface if it is there and to use the old interface if it is not.....
In the case of the ltp selinux test policy, which has a similar challenge with changing refpolicy interfaces (as well as kernel changes, e.g. introduction and enabling of open perm), I finally had to just fork a copy of the test policy in a subdirectory for RHEL5, while continuing to track the latest Fedora in the main directory. The Makefile then selects what policy to build automatically.
On Wed, 2009-07-01 at 09:18 -0400, Stephen Smalley wrote:
On Tue, 2009-06-30 at 21:46 -0400, Eric Paris wrote:
On Tue, 2009-06-30 at 17:28 -0400, Daniel J Walsh wrote:
RIght I think you would need to build on F9 for support on F11 not the other way around. Just like you would do with shared libraries. You would not expect an c executable built on F11 to run on F9?
I think he wants a single code base which can be built on F9 or F11. I might not expect that C to run, but I'd expect the same source could be compiled on either.
We aren't providing enough information for his policy to know which interface it should be using, not sure how to solve the problem, but obviously Rob want a way to use the new interface if it is there and to use the old interface if it is not.....
In the case of the ltp selinux test policy, which has a similar challenge with changing refpolicy interfaces (as well as kernel changes, e.g. introduction and enabling of open perm), I finally had to just fork a copy of the test policy in a subdirectory for RHEL5, while continuing to track the latest Fedora in the main directory. The Makefile then selects what policy to build automatically.
I do however enable the main copy of the test policy to build on multiple Fedora releases through use of ifdefs, ala:
# If the base policy defines userdom_search_generic_user_home_dirs # then no action required; else define it to # userdom_search_user_home_dirs. ifdef(`userdom_search_generic_user_home_dirs', `', ` dnl interface(`userdom_search_generic_user_home_dirs', ` userdom_search_user_home_dirs($1) ') ')
On Tue, 2009-06-30 at 16:41 -0400, Rob Crittenden wrote:
Daniel J Walsh wrote:
On 06/30/2009 10:08 AM, Rob Crittenden wrote:
In the freeIPA project we have our own SELinux policy. We support RHEL 5 up through Fedora Rawhide. With Fedora 11 we saw some problems compiling our SELinux module which Dan Walsh provided a patch for. I haven't tried this on older releases yet but I'm guessing it won't work as expected (some policies seem to have been renamed, such as corenet_non_ipsec_sendrecv() -> corenet_all_recvfrom_unlabeled()
My question is, how can we handle this in our source tree? Are we going to need to maintain per-release policies or does SELinux support some sort of versioning conditionals?
thanks
rob
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
The old interface will work, it just reports a nasty warning message when you compile it against newer policy. So I think you are safe compiling it on RHEL5 and installing it on F10/F11.
We compile it on the given platform so we need some way to support all at once.
For example, the code that builds fine on F-11 fails like this on F-9:
Compiling targeted ipa_webgui module /usr/bin/checkmodule: loading policy configuration from tmp/ipa_webgui.tmp ipa_webgui.te":77:ERROR 'syntax error' at token 'userdom_dontaudit_search_admin_dir' on line 10764: userdom_dontaudit_search_admin_dir(ipa_webgui_t)
The diff between F-11 and F-9 being:
-userdom_dontaudit_search_sysadm_home_dirs(ipa_webgui_t) +userdom_dontaudit_search_admin_dir(ipa_webgui_t)
Try adding this to your module .if file: ifdef(`userdom_dontaudit_search_admin_dir', `', ` dnl interface(`userdom_dontaudit_search_admin_dir', ` userdom_dontaudit_search_sysadm_home_dirs($1) ') ')
And then use userdom_dontaudit_search_admin_dir throughout your module .te file. Then it should get remapped if not defined.
Stephen Smalley wrote:
On Tue, 2009-06-30 at 16:41 -0400, Rob Crittenden wrote:
Daniel J Walsh wrote:
On 06/30/2009 10:08 AM, Rob Crittenden wrote:
In the freeIPA project we have our own SELinux policy. We support RHEL 5 up through Fedora Rawhide. With Fedora 11 we saw some problems compiling our SELinux module which Dan Walsh provided a patch for. I haven't tried this on older releases yet but I'm guessing it won't work as expected (some policies seem to have been renamed, such as corenet_non_ipsec_sendrecv() -> corenet_all_recvfrom_unlabeled()
My question is, how can we handle this in our source tree? Are we going to need to maintain per-release policies or does SELinux support some sort of versioning conditionals?
thanks
rob
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
The old interface will work, it just reports a nasty warning message when you compile it against newer policy. So I think you are safe compiling it on RHEL5 and installing it on F10/F11.
We compile it on the given platform so we need some way to support all at once.
For example, the code that builds fine on F-11 fails like this on F-9:
Compiling targeted ipa_webgui module /usr/bin/checkmodule: loading policy configuration from tmp/ipa_webgui.tmp ipa_webgui.te":77:ERROR 'syntax error' at token 'userdom_dontaudit_search_admin_dir' on line 10764: userdom_dontaudit_search_admin_dir(ipa_webgui_t)
The diff between F-11 and F-9 being:
-userdom_dontaudit_search_sysadm_home_dirs(ipa_webgui_t) +userdom_dontaudit_search_admin_dir(ipa_webgui_t)
Try adding this to your module .if file: ifdef(`userdom_dontaudit_search_admin_dir', `', ` dnl interface(`userdom_dontaudit_search_admin_dir', ` userdom_dontaudit_search_sysadm_home_dirs($1) ') ')
And then use userdom_dontaudit_search_admin_dir throughout your module .te file. Then it should get remapped if not defined.
This is exactly what I was looking for, thanks.
rob
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Dominick Grift -
Eric Paris -
Rob Crittenden -
Stephen Smalley