Learn more about these different git repos.
Other Git URLs
Use case:
SELinux user context needs to be assigned to the user when user logs into the system. It is very similar to HBAC except that it is a tag associated with the user-host combination instead of yes/no as in case of HBAC.
On one hand it makes sense to leverage the HBAC infrastructure the deployment might have so that the user-host relations defined in HBAC do not need to be redefined once again. On the other hand we can't assume that HBAC infrastructure is in place. In this case SELLnux rules should be definable independently.
Here is some idea how that can be done:
Let us forget about the HBAC for a moment and say we have to support SELinux objects in IPA. So we will have following objects in LDAP:
SELinux Object: - User (Pointer to identity represented by user or group - it is a multi value attribute so can point to users and groups) - Host (Pointer to host identity represented by host or host group - it is a multi value attribute so can point to hosts and groups of hosts) - SELinux user - Priority - Is default (means if not matched this is the default SELinux user to use)
The current HBAC object looks like this: - User (Pointer to identity represented by user or group - it is a multi value attribute so can point to users and groups) - Host (Pointer to host identity represented by host or host group - it is a multi value attribute so can point to hosts and groups of hosts) - Service (Pointer to login service "sudo", "ssh", "telnet", "ftp" etc. or group of those - it is a multi value attribute as above). - From Host (Pointer to host identity represented by host or host group or some external unmanaged host- it is a multi value attribute so can point to hosts and groups of hosts) - Time (when the rule is applicable - was temporarily removed from HBAC) - Allow/Deny
The SELinux user context is somewhat related to HBAC but only to allow rules. So to reduce management burden we should allow SELinux users to be defined as extension of the already existing HBAC rule. This would look like this:
SELinux Object - User host definition - Pointer to HBAC rule
--or-- - Define those: - User (Pointer to identity represented by user or group - it is a multi value attribute so can point to users and groups) - Host (Pointer to host identity represented by host or host group - it is a multi value attribute so can point to hosts and groups of hosts) - SELinux user - Priority - Is default (means if not matched this is the default SELinux user to use)
If you want to use just HBAC or just SELinux you can, but you can also link then together if you want and leverage User - Host definition specified in the allow rule in the SELinux rule. On SSSD side these objects will be cached in the same way as defined by LDAP on the server side. And when the SSSD needs to say yes/no it will consult just HBAC. If it needs to do just SELinux it will need to cache SELinux users. If an SELInux rule refers to an HBAC rule it will be pulled too even if the SSSD is not configured to enforce or check HBAC.
The corresponding freeipa ticket is: https://fedorahosted.org/freeipa/ticket/755
Fields changed
owner: somebody => sgallagh
milestone: SSSD 1.6.0 => SSSD 1.7.0
patch: => 0 rhbz: =>
The original idea about SELinux integration with SSSD is here: - http://www.freeipa.org/page/Integration_with_SELinux#pam_ipa_and_PAM_Responder - http://www.freeipa.org/page/Integration_with_SELinux#pam_selinux
Couple options: - SSSD will drop a file into a specific directory. This file will contain all the rules that apply to this user on a given machine. The issue is that SELinux would not understand the login service groups so all login service groups should be expanded. - pam_sss will get information from SSSD call into pam_selinux itself.
The second option is a bit more work. If it is too much work the first option might be chosen as the initial implementation.
BZ https://bugzilla.redhat.com/show_bug.cgi?id=766000
rhbz: => 766000
rhbz: 766000 => [https://bugzilla.redhat.com/show_bug.cgi?id=766000 766000]
blockedby: => blocking: => milestone: SSSD 1.8.0 => SSSD 1.7.91 (1.8.0 beta 1)
component: SSSD => SELinux owner: sgallagh => jzeleny
priority: major => critical
Fixed by: - c32484c - 213ce2a - 7a65556 - 9674f0f - 823a5b3 - 4c11f75 - 45fea2d - 264bbfe - ad07ed3 - 16dff70 - 2d0550a - 1a85312 - 28eff88
feature_milestone: => resolution: => fixed status: new => closed
Metadata Update from @dpal: - Issue assigned to jzeleny - Issue set to the milestone: SSSD 1.8 beta
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/1836
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.