9:08 a.m.
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
9:27 a.m.
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/ser...
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
3:27 p.m.
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(a)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.
3:41 p.m.
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(a)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
4:28 p.m.
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(a)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(a)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?
8:46 p.m.
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
9:31 p.m.
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
8:18 a.m.
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.
--
Stephen Smalley
National Security Agency
9:52 a.m.
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)
')
')
--
Stephen Smalley
National Security Agency
10 a.m.
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(a)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
National Security Agency
2:07 p.m.
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(a)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
5410
days inactive
5411
days old
selinux@lists.fedoraproject.org
10 comments
5 participants
participants (5)
-
Daniel J Walsh -
Dominick Grift -
Eric Paris -
Rob Crittenden -
Stephen Smalley