Martin Kosek wrote:
On 02/12/2014 09:33 PM, Josh wrote:
On Feb 12, 2014, at 3:20 PM, Rob Crittenden <rcrit...@redhat.com> wrote:
On Feb 11, 2014, at 2:52 PM, Rob Crittenden <rcrit...@redhat.com> wrote:
On Feb 11, 2014, at 2:44 PM, Rob Crittenden <rcrit...@redhat.com
I have a situation where I need to support more than 1024 categories
on a system. I modified the selinuxusermap.py file to check for the
number of categories I need but ipa still responds with the original
error message. Do I need to restart any of the services?
Here is the command that was run and the output after applying the
ipa: ERROR: invalid 'ipaselinuxusermaporder': SELinux user
'staff_u:s0-s15:c0.c16383' is not valid: Invalid MCS value, must
match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123]
Have you updated your SELinux policy to support a larger MCS range? If
not then this will get you past the IPA validator but it won't work
with SELinux. See semanage(8).
Yes. I’m trying to set the SELinux categories in freeipa because when
you have lots of categories all semanage commands slow down (way down).
For other people’s knowledge, this requires recompilation of the
Ok, then your patch looks reasonable. The current code is for the default
values and we haven't had cause to make this configurable before now. You might
consider filing a ticket in our trac about this.
As it is for a very unique situation which most people won’t encounter I don’t
think it’s worth making configurable.
Also note that this change will be lost on your next IPA upgrade, and you'll
need to make this change on any IPA master you want these values to be managed.
The data will remain unchanged, but the original python values will be restored
if you update the packages.
I’m ok with that because the values only need to be set during initial setup.
Any idea why the validator isn’t being modified?
I don't believe validators are currently extensible in the IPA framework. That
might be something we need to look at as well.
Thanks for the help.
Sure. I'm glad we made at least obvious enough for you to be able to work
So I'm just curious about the need for this. You mentioned that semanage slows
way down. Have you talked to the SELinux team about this? They've been quite
responsive to our needs in the past, they may be able to fix something for you
I’m not sure if my coworker has talked to them about it directly, no. I’ll
ping him to see if it’s something we want to get worked on moving forward.
On a more general note, we haven't had a lot of user feedback on the SELinux
user map feature. Do you have any other suggestions on things we might do to
Nothing directly but I can describe how we’re using it and where some of the
perceived pain points are. Their impact is negligible though so we haven’t
felt the need to investigate better ways to work around them.
We’ve got a network of systems running both targeted and MLS SELinux policy.
What this means is that we must define both valid selinux context is the user
map. I.e. we define both staff_u:s0-s0:c0.c1023 and staff_u:s0-s15:c0.c1023 in
the user map. We then use host groups and multiple user maps to map
appropriately. Our commands might be easier to understand:
ipa hostgroup-add mls --desc="MLS SELinux Group”
ipa hostgroup-add-member mls --hosts=mlshost1,mlshost2
ipa hostgroup-add targeted --desc="Targeted SELinux Group”
ipa hostgroup-add-member targeted --hosts=appsrv1,appsrv2
ipa selinuxusermap-add staff_u --selinuxuser=staff_u:s0-s0:c0.c1023
ipa selinuxusermap-add staff_u_MLS --selinuxuser=staff_u:s0-s15:c0.c1023
ipa selinuxusermap-add-host staff_u --hostgroups=targeted
ipa selinuxusermap-add-host staff_u_MLS --hostgroups=mls
ipa selinuxusermap-add-user staff_u --groups=wheel
ipa selinuxusermap-add-user staff_u_MLS --groups=wheel
It might be more straightforward if we didn’t have to split the configuration
like this but thanks to the flexibility of FreeIPA it’s very easy to do.
Nice. Not many of our users got back to us with experience on using the
advanced use of the SELinux feature - so feedback welcome!
Rob, I am wondering if it would make sense to extend the FreeIPA to allow
SELinux user map rules with more SELinux users, per policy? I.e. have a rule
# ipa selinuxusermap-show staff_u
Rule name: staff_u
SELinux User: staff_u:s0-s0:c0.c1023
SELinux User (mls): staff_u:s0-s15:c0.c1023
User Groups: wheel
Host Groups: selinuxhosts
This proposed rule structure is not ideal and would require updated IPA&SSSD on
all machines but it should explain the idea.
I think this would be handy if one had a lot of SELinux user categories
but I don't think that is typical. Then again, I hadn't considered the
case of different MLS levels either, so take it with a grain of salt.
Freeipa-users mailing list