Manage SELinux users centrally #1836

sssd-bot · 2020-05-02T12:17:35Z

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/794

Created at 2011-02-10 21:58:14 by dpal
Closed as Fixed
Assigned to jzeleny
Associated bugzillas
- https://bugzilla.redhat.com/show_bug.cgi?id=766000

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

Comments

Comment from dpal at 2011-03-03 15:07:56

Fields changed

owner: somebody => sgallagh

Comment from dpal at 2011-03-31 15:10:13

Fields changed

milestone: SSSD 1.6.0 => SSSD 1.7.0

Comment from dpal at 2011-12-09 21:11:25

Fields changed

patch: => 0
rhbz: =>

Comment from dpal at 2011-12-09 21:13:29

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.

Comment from dpal at 2011-12-09 21:31:58

BZ https://bugzilla.redhat.com/show_bug.cgi?id=766000

rhbz: => 766000

Comment from mkosek at 2011-12-16 15:59:55

Fields changed

rhbz: 766000 => [https://bugzilla.redhat.com/show_bug.cgi?id=766000 766000]

Comment from dpal at 2012-01-05 15:17:09

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.8.0 => SSSD 1.7.91 (1.8.0 beta 1)

Comment from sgallagh at 2012-01-05 17:15:03

Fields changed