| Identity Management GuideChapter 15. Policy: Configuring Host-Based Access ControlIdM can control access to both machines and the services on those machines within the IdM domain. The rules define who can access what within the domain, not the level of access (which are defined by system or application settings). These access control rules grant access, with all other users and hosts implicitly denied. This is called host-based access control because the rule defines what hosts (source) are allowed to access other hosts (targets) within the domain. This access can be further broken down to users and services. Using host-based access control requires SSSD to be installed and configured on the IdM client machine. 15.1. About Host-Based Access ControlHost-based access control rules (which are described in Chapter 15, Policy: Configuring Host-Based Access Control) can be applied to individual hosts. However, using host groups allows centralized, and potentially simplified, access control management because an access control rule only needs to be defined once and then it is applied immediately and consistently to all the hosts within the group. While access must be explicitly granted to users and hosts within the IdM domain, IdM servers are configured by default with an allow all access control rule which allows access for every host within the domain to every host within the domain. To create an IdM server without the default allow all rule, run ipa-server-install with the --no_hbac_allow option. The rule first defines things that can be accessed, and there are two types of entities: Hosts, or target hosts, within the IdM domain. Services on the target hosts. Multiple services can be combined into service groups. The service group can be modified without having to edit the access control rule itself.
The rule also sets who can have access (the IdM domain user) and what they can use to access the targets (the source host). It is possible to use categories for users, source hosts, and target hosts instead of adding each one individually to the access control rule. The only supported category is all. The entities in host-based access control rules follow the Kerberos principal entries: users, hosts (machines), and services. Users, source hosts, and target hosts can be added directly to host-based access control rules. However, services must be flagged first and then added to the access control rules. 15.2. Creating Host-Based Access Control Entries for Services and Service GroupsAny PAM service can be identified as to the host-based access control (HBAC) system in IdM. The service entries used in host-based access control are separate from adding a service to the IdM domain. Adding a service to the domain makes it a recognized resource which is available to other resources. Adding a domain resource to the host-based access control configuration allows administrators to exert defined control over what domain users and what domain clients can access that service. Some common services are already configured as HBAC services, so they can be used in host-based access control rules. Additional services can be added, and services can be added into service groups for simpler management. 15.2.1. Adding HBAC Services15.2.1.1. Adding HBAC Services in the Web UIClick the Policy tab. Click the Host-Based Access Control subtab, and then select the HBAC Services link. Click the Add link at the top of the list of services. Enter the service name and a description. Click the Add button to save the new service.
15.2.1.2. Adding Services in the Command LineThe service is added to the access control system using the hbacsvc-add command, specifying the service by the name that PAM uses to evaluate the service. For example, this adds the tftp service: # ipa hbacsvc-add --desc="TFTP service" tftp-------------------------Added HBAC service "tftp"------------------------- 15.2.2. Adding Service GroupsOnce the individual service is added, it can be added to the access control rule. However, if there a large number of services, then it can require frequent updates to the access control rules as services change. Identity Management also allows groups of services to added to access control rules. This makes it much easier to manage access control, because the members of the service group can be changed without having to edit the rule itself. 15.2.2.1. Adding Service Groups in the Web UIClick the Policy tab. Click the Host-Based Access Control subtab, and then select the HBAC Service Groups link. Click the Add link at the top of the list of service groups. Enter the service group name and a description. Click the Add and Edit button to go immediately to the service configuration page. At the top of the HBAC Services tab, click the Add link. Click the checkbox by the names of the services to add, and click the right arrows button, >>, to move the command to the selection box. Click the Add button to save the group membership.
15.2.2.2. Adding Service Groups in the Command LineFirst create the service group entry, then create the service, and then add that service to the service group as a member. For example: $ ipa hbacsvcgroup-add --desc="login services" login--------------------------------Added HBAC service group "login"-------------------------------- Service group name: login Description: login services$ ipa hbacsvc-add --desc="SSHD service" sshd-------------------------Added HBAC service "sshd"-------------------------$ ipa hbacsvcgroup-add-member --hbacsvcs=sshd login Service group name: login Description: login services-------------------------Number of members added 1------------------------- IdM defines two default service groups: SUDO for sudo services and FTP for services which provide FTP access. 15.3. Defining Host-Based Access Control RulesAccess controls, at a high level, define who has access to what. The who can be either a user or a host (the source host), and the what can be either a host (target host), service, or service group, or a combination of the three. 15.3.1. Setting Host-Based Access Control Rules in the Web UIClick the Policy tab. Click the Host-Based Access Control subtab, and then select the HBAC Rules link. Click the Add link at the top of the list of host-based access control rules. Enter the name for the rule. Click the Add and Edit button to go immediately to set the configuration for the rule. There are a number of configuration areas for the rule. The four basic elements are who the rule applies to, what hosts users can use to access resources (the source), what hosts allow access (the target), and, optionally, what services can be accessed. In the Who area, select the users or user groups to which the access control rule is applied. To apply the rule to all IdM users, select the Anyone radio button. To apply the rule to a specific set of users or user groups: Select the Specified Users and Groups radio button. Click the + Add link at the right of the users list. Click the checkbox by the users to add to the rule, and click the right arrows button, >>, to move the users to the selection box. Click Add.
In the Accessing area, select the target hosts which can be accessed through this access control rule. To apply the rule to all IdM hosts, select the Any Host radio button. To apply the rule to a specific set of hosts or host groups: Select the Specified Hosts and Groups radio button. Click the + Add link at the right of the hosts list. Click the checkbox by the hosts to include with the rule, and click the right arrows button, >>, to move the hosts to the selection box. Click Add.
In the Via Service area, select specific services on the target hosts which the users are allowed to use to access target machines. To apply the rule to all IdM hosts, select the Any Service radio button. To apply the rule to a specific set of hosts or host groups: Select the Specified Services and Groups radio button. Click the + Add link at the right of the commands list. Click the checkbox by the services or groups to include with the rule, and click the right arrows button, >>, to move the services to the selection box. Click Add.
In the From area, select the source hosts, from which users can access the target hosts. To apply the rule to all IdM hosts, select the Any Host radio button. To apply the rule to a specific set of hosts or host groups: Select the Specified Hosts and Groups radio button. Click the + Add link at the right of the hosts list. Click the checkbox by the hosts to include with the rule, and click the right arrows button, >>, to move the hosts to the selection box. Click Add.
15.3.2. Setting Host-Based Access Control Rules in the Command LineThe basic outline of all the access control commands is: $ ipa hbacrule-add* options ruleName To set every user, every host as a source host, or every host as a target, use the category options, such as --usercat=all. Example 15.1. Granting All Access to One Host One simple rule is to grant every user and every source host access to a single server. The first command creates the entry and uses the category options to apply every user and every host as a source host. $ ipa hbacrule-add --usercat=all --srchostcat=all allGroup--------------------------Added HBAC rule "allGroup"-------------------------- Rule name: allGroup User category: all Source host category: all Enabled: TRUE The second rule adds the target host, using the hbacrule-add-host command: $ ipa hbacrule-add-host --hosts=server.example.com allGroup Rule name: allGroup User category: all Source host category: all Enabled: TRUE Successful hosts/hostgroups: member host: server.example.com-------------------------Number of members added 1------------------------- Example 15.2. Adding Control for a Single User to a Service Another access control method is to specify which services users are allowed to use to access the target hosts. First, for the user to have access to every machine, every host must be added as both a host and target. This can be done using the category options: $ ipa hbacrule-add --hostcat=all --srchostcat=all sshd-jsmith Since the access control rule applies to a specific user, the user is added to the rule using the hbacrule-add-user command: $ ipa hbacrule-add-user --users=jsmith sshd-jsmith Then, the service is added to the access control rule. (The service should have already been added to the access control system using the hbacsvc-add command.) This is the service that the user can use to connect to the machine. $ ipa hbacrule-add-service --hbacsvcs=sshd sshd-jsmith Example 15.3. Adding a Service Group to the Rule While a single service can be added to a rule, it is also possible to add an entire service group. Like a single service, this uses the hbacrule-add-service command, only with the --hbacsvcgroups option that specifies the group name. $ ipa hbacrule-add-service --hbacsvcgroups=login loginRule Table 15.1. Host-Based Access Control Command and Options | Command | Description | Arguments | Source or Target Entry |
|---|
| hbacrule-add | Adds a new host-based access control rule. | --usercat=all, which applies the rule to every user --hostcat=all, which sets every host as an allowed target server --srchostcat=all, which sets every host as an allowed source server --servicecat=all, which sets every configured service as an allowed target service ruleName, which is the required unique identifier for the new rule
| | | hbacrule-add-host | Adds a target host to the access control rule. A target host can be accessed by other servers and users in the domain. | --hosts, which adds an individual server or command-separated list of servers as an allowed target server --hostgroups, which adds a host group to the rule and every host within the host group is an allowed target server ruleName, which is the rule to which to add the target server
| Target | | hbacrule-add-service | Adds a service type to the rule. | --hbacsvcs, which adds an individual service type or a comma-separated list of service type as an allowed target service --hbacsvcgroups, which adds a service group to the rule and every service within the service group is an allowed target service ruleName, which is the rule to which to add the target service
| Target | | hbacrule-add-sourcehost | Adds a server to the list of servers that can be used to access domain services and target servers. | --hosts, which adds an individual server or command-separated list of servers as an allowed source server --hostgroups, which adds a host group to the rule and every host within the host group is an allowed source server ruleName, which is the rule to which to add the source server
| Source | | hbacrule-add-user | Adds a user to the access control rule. The user is then able to access any allowed target host or service within the domain, from any configured source host. | --users, which adds an individual user or command-separated list of users to the rule --groups, which adds a user group to the rule and, thus, every user within the group ruleName, which is the rule to which to add the user
| Source | | hbacrule-disable | hbacrule-enable | Disables or enables a host-based access control rule. Rules can be disabled if their behavior needs to be evaluated (for troubleshooting or to test a new rule). | ruleName, which is the rule to disable or enable | |
15.4. Testing Host-Based Access Control RulesImplementing host-based access controls effectively can be tricky because it requires that all of the hosts be properly configured and the access is properly applied to users and services. The hbactest command can test different host-based access control scenarios to make sure that the rules are working as expected. The hbactest command does not work with trusted Active Directory users. Active Directory user/group associations are determined dynamically, as a user logs in, and those data are not stored in the IdM LDAP directory. The hbactest command, then, is unable to resolve the group memberships to check how access control rules will be applied. 15.4.1. The Limits of Host-Based Access Control ConfigurationWhen a request is made to one of the domain services, the identifier of the source host is sent to a PAM interface for the login application (like OpenSSH, telnet, or rlogin) which is used to access SSSD on the target host machine. This identifier can be the hostname, the IP address, or even the alias of the source host. This is essentially a long chain, from the source host to the target host to the service. The access control mechanism uses the identifier that is sent to the SSSD service on the target machine to verify that the source host has proper authorization granted in an access control rule. However, if the identifier sent to SSSD cannot be traced back to the source host, then authorization fails. This can happen if any part of the host information does not match the access control rule configuration: The source host uses an alias which is not listed in the rule. The domain service on the target host sends an IP address instead of the hostname. DNS is misconfigured and does not return the proper information for the DNS lookup or reverse lookup. The client sends a malformed string to SSSD.
The name that is sent by the client must match the name in the rule, otherwise host-based access control fails. The access control configuration should always be tested before it is implemented to prevent authorization failures. Host-based access control rules depend on a lot of interactions - between hosts, services, DNS lookups, and users. If any element is misconfigured, then the rule can behave in unexpected ways. Identity Management includes a testing tool to verify that access control rules are behaving in the expected way by testing the access in a defined scenario. There are several situations where this testing is useful: A new rule needs to be tested before it is implemented. There are problems with the existing rules, and the testing tool can identify what rule is behaving badly. A subset of existing rules can be tested to see how they are performing.
15.4.2. Test Scenarios for Host-Based Access Control (CLI-Based)The hbactest command does not work with trusted Active Directory users. Active Directory user/group associations are determined dynamically, as a user logs in, and those data are not stored in the IdM LDAP directory. The hbactest command, then, is unable to resolve the group memberships to check how access control rules will be applied. The hbactest command tests configured host-based access control rules in very specific situations. A test run defines: The user to run the operation as to test the rule performance for that user (--user). From the source host X (--srchost). Using the login client Y (--service). To target host Z (--host). The rule to test (--rules); if this is not used, then all enabled rules are tested. Optional The hbactest returns detailed information about which rules were matched, not matched, or invalid. This detailed rule output can be disabled using --nodetail, so the test simply runs and returns whether access was granted.
The hbactest script does not actually connect to the target host. Instead, it uses the rules within the IdM database to simulate how those rules would be applied in a specific situation as if an SSSD client were connecting to the IdM server. More briefly, it performs a simulated test run based on the given information and configuration, but it does not actually attempt a service request against the target host. Example 15.4. Testing All Active Rules The most basic command checks all active rules. It requires a specific connection scenario, so the user, login service, source host, and target host have to be given, and the testing tool checks the connection. $ ipa hbactest --user=jsmith --srchost=source.example.com --host=target.example.com --service=ssh--------------------Access granted: True-------------------- notmatched: my-second-rule notmatched: my-third-rule matched: myrule matched: allow_all Example 15.5. Testing a Specific Rule It is possible to check a specific rule (or several rules). $ ipa hbactest --user=jsmith --srchost=source.example.com --host=target.example.com --service=ssh --rules=myrule---------------------Access granted: True--------------------- notmatched: myrule Example 15.6. Testing Specific Rules Plus All Enabled The --rules option lists specific rules to test, but it may be useful to test the specified rules against all of the enabled rules in the domain. This can be done by adding the --enabled option, which includes the (unspecified) enabled rules along with the specified rules. $ ipa hbactest --user=jsmith --srchost=source.example.com --host=target.example.com --service=ssh --rules=myrule --enabled--------------------Access granted: True-------------------- matched: my-second-rule notmatched: my-third-rule matched: myrule matched: allow_all It is possible to run a similar comparison against disabled rules by using the --disable option. With the --rules option, the specified rule plus all of the disabled rules are checked. With the --disabled option, all disabled rules are checked. 15.4.3. Testing Host-Based Access Control Rules in the UITesting host-based access control can help confirm that the rule performs as expected before it is deployed or to troubleshoot a rule once it is already active. The hbactest command does not work with trusted Active Directory users. Active Directory user/group associations are determined dynamically, as a user logs in, and those data are not stored in the IdM LDAP directory. The hbactest command, then, is unable to resolve the group memberships to check how access control rules will be applied. By the nature of host-based access control rules, a test must define and verify a very specific set of criteria, A test run defines: The user to run the operation as to test the rule performance for that user (Who). To target host Z (Accessing). Using the login client Y (Via Service). From the source host X (From); this can be an IdM client or an external host. The rule to test; if this is not used, then all enabled rules are tested (Rules).
The test environment is defined on the HBAC TEST page in the Host Based Access Control tab under Policy. A series of tabs is set up for each configuration step. Once the environment is defined, then the test is run simply by clicking a button on the Run Test page. The results show clearly whether access was granted or denied to the users, and then runs through the rules which matched the given parameters. To change some of the parameters and check for other results, click the New Test button at the bottom of the test results page. If that button is not selected, the form is not reset, so a new test will not run, even if test settings are changed. Chapter 16. Policy: Defining SELinux User MapsSecurity-enhanced Linux (SELinux) sets rules over what system users can access processes, files, directories, and system settings. Both the system administrator and applications themselves can define security contexts that restrict or allow user access and even access from other applications. As part of defining centralized security policies in the Identity Management domain, Identity Management provides a way to map IdM users to SELinux users and automatically grant or restrict access to clients and services within the IdM domain, per host, based on the defined SELinux policies. 16.1. About Identity Management, SELinux, and Mapping UsersSecurity-enhanced Linux defines kernel-level, mandatory access controls for how users, processes, and applications can interact with other resources on a system. These rules for interactions, called contexts, look at the data and behavior characteristics of different objects on the system and then set rules, called policies, which create contexts based on the security implications of each specific object. This is in contrast to higher-level discretionary access controls which are concerned primarily with file ownership and user identity, without accounting for data criticality or applciation behavior. System users are associated with an SELinux role. The role is assigned both a multi-layer security context (MLS) a multi-category security context (MCS). The MLS/MCS contexts confine users to what processes, files, and operations they can access on the system. SELinux users and policies function at the system level, not the network level. This means that SELinux users are configured independently on each system. While this is acceptable in many situations - SELinux has common defined system users and SELinux-aware services define their own policies - it has some issues when dealing with remote users and systems that access local resources. Remote users and services can get shuffled into a default guest context without a lot of intelligence about what their actual SELinux user and role should be. This is how Identity Management can cleanly integrate an identity domain with local SELinux services. Identity Management can map IdM users to configured SELinux roles per host. Mapping SELinux and IdM users improves user administration: Remote users can be granted appropriate SELinux user contexts based on their IdM group assignments. This also allows administrators to consistently apply the same policies to the same users without having to create local accounts or reconfigure SELinux. SELinux users are automatically updated as hosts are added to the IT environment or as users are added, removed, or changed, without having to edit local systems. SELinux policies can be planned and related to domain-wide security policies through settings like IdM host-based access control rules. Administrators gain environment-wide visibility and control over how users and systems are assigned in SELinux.
SELinux user maps are comprised of three parts: the SELinux user for the system, an IdM user, and an IdM host. These define two separate relationships. First, it defines a map for the SELinux user on a specific host (the local or target system). Second, it defines a map for the SELinux user and the IdM user. This arrangement allows administrators to set different SELinux users for the same IdM users, depending on which host they are accessing. SELinux user maps work with the Systerm Security Services Daemon (SSSD) and the pam_selinux module. When a remote user attempts to log into a machine, SSSD checks its IdM identity provider to collect the user information, including any SELinux maps. The PAM module then processes the user and assigns it the appropriate SELinux user context. The core of an SElinux mapping rule is the SELinux system user. Each map is associated with the SELinux user first. The SELinux users which are available for mapping are configured in the IdM server, so there is a central and universal list. These are SELinux users which are configured on every host in the IdM domain. By default, there are five common SELinux users defined: In the IdM server configuration, each SELinux user is configured with both its username and its MLS/MCS range, SELinux_username:MLS[:MCS], and this format is used to identify the SELinux user when configuring maps. The IdM user and host configuration is very flexible. Users and hosts can be explicitly and individually assigned to an SELinux user map individually, or user groups or host groups can be explicitly assigned to the map. An extra layer of security is possible by using host-based access control rules. As long as the host-based access control rule defines a user and a host, it can be used for an SELinux user map. Host-based access control rules (described in Chapter 15, Policy: Configuring Host-Based Access Control) help integrate SELinux user maps with other access controls in IdM and can help limit or allow host-based user access for remote users, as well as defining local security contexts. If a host-based access control rule is associated with an SELinux user map, the host-based access control rule cannot be deleted until it is removed from the SELinux user map configuration. 16.2. Configuring SELinux Users in IdMSELinux user maps, as the name implies, creates an association between an SELinux user and an IdM user. Before that association can be established, the IdM server has to be aware of what SELinux users are configured on the systems it manages. The available SELinux users are part of the IdM server configuration. This is a list, in order from most to least confined, of the SELinux users. The SELinux user entry itself has this format: SELinux_username:MLS[:MCS]
The individual user entries are separated with a dollar sign ($). Since there is no requirement on user entries to have an SELinux map, many entries may be unmapped. The IdM server configuration can also set a default SELinux user (which is part of the larger SELinux map list) to use for otherwise unmapped IdM user entries. In the top menu, click the IPA Server main tab and the Configuration subtab. Scroll to the bottom of the list of server configuration areas, to SELINUX OPTIONS. Set the SELinux user configuration. There are two areas that can be edited: the prioritized list of SELinux users and the default SELinux user to use for unmapped IdM users. The SELinux user map order gives the list of SELinux users, defined on the local Linux system , which are available for configuring mapping rules. This is a prioritized list, from most to least confined. Each SELinux user has the format SELinux_user:MLS. The Default SELinux user field sets the SELinux user to use for unmapped IdM users. Click the Update link at the top of the page to save the changes.
Before SELinux mapping rules can be created, there has to be a defined and universal list of SELinux users which are available to be mapped. This is set in the IdM server configuration: [jsmith@server ~]$ ipa config-show... SELinux user map order: unconfined_u:s0-s0:c0.c1023$guest_u:s0$xguest_u:s0$user_u:s0-s0:c0.c1023$staff_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023 The SELinux user settings can be edited using the config-mod command. Example 16.1. List of SELinux Users The complete list of SELinux users is passed in the --ipaselinuxusermaporder option. This list sets a priority order, from most to least confined users. The SELinux user entry itself has this format: SELinux_user:MLS:MCS
The individual user entries are separated with a dollar sign ($). For example: [jsmith@server ~]$ ipa config-mod --ipaselinuxusermaporder="unconfined_u:s0-s0:c0.c1023$guest_u:s0$xguest_u:s0$user_u:s0-s0:c0.c1023$staff_u:s0-s0:c0.c1023" The default SELinux user, used for unmapped entries, must be included in the user map list or the edit operation fails. Likewise, if the default is edited, it must be changed to a user in the SELinux map list or the map list must be updated first. Example 16.2. Default SELinux User IdM users are not required to have a specific SELinux user mapped to their account. However, the local system still checks the IdM entry for an SELinux user to use for the IdM user account. The default SELinux user sets the fallback user to use for unmapped IdM user entries; this is, by default, the default SELinux user for system users on Red Hat Enterprise Linux, unconfined_u. This default user can be changed with the --ipaselinuxusermapdefault. For example: [jsmith@server ~]$ ipa config-mod --ipaselinuxusermapdefault="guest_u:s0" 16.3. Mapping SELinux Users and IdM UsersAn SELinux map associates an SELinux user with an IdM user (or users). However, SELinux settings are local to each host system, so a map not only needs to map the SELinux user with an IdM user but also with a host system. The rule definition primarily identifies the SELinux user; the SELinux user is the basis of the rule. The other half of the map is comprised of defined IdM users and defined IdM hosts. (There can be one single user or host or multiple users and hosts or user and host groups in the map.) The users and hosts can be defined either by explicitly listing users and hosts or by referencing a host-based access control rule. The host-based access control rule must contain users and hosts, not just services. In the top menu, click the Policy main tab and the SELinux User Mappings subtab. In the list of mappings, click the Add button to create a new map. Enter the name for the map and the SELinux user exactly as it appears in the IdM server configuration. SElinux users have the format SELinux_username:MLS[:MCS]. Click Add and Edit to add the IdM user information. As described in the introduction, an SELinux map has three parts: the SELinux user and an IdM user/host pairing. That IdM user/host pair can be defined in one of two ways: it can be set for explicit users on explicit hosts, or it can be defined using a host-based access control rule. To set a host-based access control rule, select the rule from the drop-down menu in the General area of the configuration. Using a host-based access control rule also introduces access controls on what hosts a remote user can use to access a target machine. Only one host-based access control rule can be set. Alternatively, scroll down the Users and Hosts areas, and click the Add link to assign users, user groups, hosts, or host groups to the SELinux map. Select the users (or hosts or groups) on the left, click the right arrows button (>>) to move them to the Prospective column, and click the Add button to add them to the rule. Either a host-based access control rule can be given or the users and hosts can be set manually. Both options cannot be used at the same time. Click the Update link at the top to save the changes to the SELinux user map.
An SELinux map rule has three fundamental parts: The SELinux user (--selinuxuser) The user or user groups which are associated with the SELinux user (--users or --groups) The host or host groups which are associated with the SELinux user (--hosts or --hostgroups) Alternatively, a host-based access control rule which specifies both hosts and users in it (--hbacrule)
A rule can be created with all information at once using the selinuxusermap-add command. Users and hosts can be added to a rule after it is created by using the selinuxusermap-add-user and selinuxusermap-add-host commands, respectively. Example 16.3. Creating a New SELinux Map The --selinuxuser value must be the SELinux user name exactly as it appears in the IdM server configuration. SElinux users have the format SELinux_username:MLS[:MCS]. Both a user and a host (or appropriate groups) must be specified for the SELinux mapping to be valid. Users, hosts, or groups can be specified in comma-separated lists. [jsmith@server ~]$ ipa selinuxusermap-add --users=jsmith,bjensen,jrockford --hosts=server.example.com,test.example.com --selinuxuser="xguest_u:s0" selinux1 Example 16.4. Creating an SELinux Map with a Host-Based Access Control Rule The --hbacrule value identifies the host-based access control rule to use for mapping. Using a host-based access control rule introduces access controls on what hosts a remote user can use to access a target machine, along with applying SELinux contexts after the remote user as logged into the target machine. The access control rule must specify both users and hosts appropriately so that the SELinux map can construct the SELinux user, IdM user, and host triple. Only one host-based access control rule can be specified. [jsmith@server ~]$ ipa selinuxusermap-add --hbacrule=webserver --selinuxuser="xguest_u:s0" selinux1 Example 16.5. Adding a User to an SELinux Map While all of the users and hosts can be added to a map when it is created, users and hosts can also be added after the rule is created. This is done using a specific command, either selinuxusermap-add-user or selinuxusermap-add-host. [jsmith@server ~]$ ipa selinuxusermap-add-user --users=jsmith selinux1 It is not necessary to use a separate command to add a host-based access control rule after the rule is configured because there can only be one. If the selinuxusermap-mod command is used with the --hbacrule option, it adds the host-based access control rule or overwrites the previous one. A specific user or host can be removed from an SELinux map by using either the selinuxusermap-remove-host or selinuxusermap-remove-user command. Example 16.6. Removing a User from an SELinux Map As with adding a user to a ion> value identifies the host-based access control rule to use for mapping. The access control rule must specify both users and hosts appropriately so that the SELinux map can construct the SELinux user, IdM user, and host triple. [jsmith@server ~]$ ipa selinuxusermap-remove-user --users=jsmith selinux1 16.4. Troubleshooting SELinux Login ProblemsSELinux maps only work for remote users, not for users with a local account. When a remote user logs in, authenticating against the IdM server, then the PAM SElinux modules create a file for that user in /etc/selinux/policy_name/logins/login. If that file does not exist, then it means that SSSD is not properly configured to use the IdM server as one of its identity providers. This is required for SELinux mapping to work. Configuring SSSD is covered in the Red Hat 6 Deployment Guide. If the file exists but the remote user was given the wrong SELinux context, then the pam_selinux module may not be properly configured in the PAM stack. This is the module that reads the SELinux information and sets the user context. If the module is missing, then nothing processes the SELinux map and the user is defined a default context on the system. |
| |
