How FreeIPA SELinux user maps confine users by host
Most teams that reach for an SELinux user map want one thing: a regular domain user who logs in to a server should land in a confined SELinux user, not in the unconfined login that Linux hosts usually give by default. In FreeIPA, an SELinux user map is a policy object that tells the client, through SSSD, which SELinux user a given IdM user receives when they log in to a given host or host group. You need one when your hosts run SELinux in enforcing mode and your access model distinguishes ordinary staff from administrators who need broader privileges. Without a map, the login falls back to the SELinux default mapping on the host, and that default may not match the confinement you intended.
The map does not decide whether someone may log in at all. That decision stays with host-based access control (HBAC) rules, which are evaluated first, and the SELinux user map then determines the SELinux context of the session that HBAC has admitted. Plan the two together: an HBAC rule that allows a group onto a host, paired with a map that assigns that group a confined user such as user_u or staff_u, produces the access you describe in a design document. Confirm the exact object names, the attributes used on each map, and the default SELinux user list in the FreeIPA documentation for your version, and confirm the SELinux user names and their permitted roles in the SELinux documentation for each target distribution, since the policy shipped differs between distributions and releases.
Before you rely on a map, confirm on a test host that the intended SELinux user appears in the session, for example with id -Z run after an actual login, and that the same user is refused where the HBAC rule should refuse them. Check that sudo rules that depend on SELinux options behave as you expect for that confined user. Keep the test cases with the HBAC test results so that a later change to a map or host group can be checked against the same expectations. Confirm with your own distribution vendor which SELinux user is appropriate for administrators who must run privileged tools, because confining that group too tightly can break the tooling they use during an incident.
Which SELinux user each map should assign
This table compares the SELinux users a FreeIPA map can assign, the account types each suits, and the trade-off of each. Read it as a starting point for matching confinement to role, then confirm the exact list of SELinux users on your target OS before writing any map.
| SELinux user | Typical account type | Trade-off |
|---|---|---|
| unconfined_u | Local administrators who need broad, unrestricted shell access on the host | Provides almost no SELinux confinement, so it adds little protection beyond normal Unix permissions |
| staff_u | Staff and administrators who work interactively but should not run as root by default | Confined, but allows sudo and administrative roles, so pair it with tight sudo rules |
| user_u | Standard interactive users with no administrative duties on the host | Strong confinement for daily work, but may block tools or workflows that staff rely on |
| sysadm_u | Administrators who need administrative SELinux roles, typically reached through sudo | Stronger control for privileged work, but needs careful sudo and role testing before rollout |
| guest_u or xguest_u | Restricted or temporary accounts with minimal access to the host | Very tight confinement, but many services and desktop features may not work for these users |
| Service or automation accounts | Non-human accounts that should be confined to specific tasks | Usually better handled through service-specific policy than a general user map, so confirm the approach with your security team |
When SELinux user maps fit a host
On a typical application or utility server, the question is whether confining logins by SELinux user adds a useful boundary above the default targeted policy. A map assigns each matching IPA user or group a named SELinux user on the hosts covered by the linked HBAC rule. It changes the SELinux identity and context a session receives at login, so staff can be placed into a more restricted role than ordinary accounts. It does not change file ownership, Unix permissions, group membership or the sudo commands a user may run.
- What changes: login sessions for matched users receive the SELinux user you assign instead of the default mapping.
- What stays the same: HBAC still decides whether a login is allowed at all, and sudo rules still decide escalation.
- Where it helps: hosts where staff should start in a confined role without broad administrative domains.
- Where it adds little: hosts whose only users are service accounts, or where every user receives the same default confinement.
Before relying on the map, confirm the SELinux user each mapped account receives with id -Z after login, and check that the host's targeted policy is the one you expect.
Jump hosts are where administrators start sessions into other systems, so the SELinux user assigned there sets the starting point for everything that follows. A map is often more valuable here than on general servers because it can limit what an administrator's session can do locally before any sudo rule applies. It does not stop an administrator who holds valid sudo rights from using them, and it does not govern sessions forwarded to other hosts.
- Starting context: assign a confined SELinux user to administrator groups so sessions begin with narrower rights.
- Sudo still governs elevation: sudo SELinux options can set the role or type used for a command, so review them together with the map.
- Forwarding is outside the map: SSH agent forwarding and tunnels carry access to other hosts, which those hosts' own maps must govern.
- Shared roles: a person holding both a jump-host role and a broad administrative role should have that combination recorded and justified.
Before enforcement, test each administrator group's path from login to a privileged command on a staging jump host, and confirm the policy on that host includes every SELinux user the maps name.
Hosts that process regulated data usually need evidence that access is limited, defined and recorded. A map contributes to that story by showing a named SELinux identity per user group and host group, but it is one control among identity, authorization, logging and hardening. No map by itself satisfies a requirement. An independent auditor decides whether a set of controls meets a given requirement, and your team needs to show how each map ties to a specific control.
- Defined identity per host: the map records which SELinux user applies to which IPA group on which host group.
- Change history: map changes are IPA configuration changes, so keep their history and review them on a schedule your assessor accepts.
- Scope of confinement: decide whether the workload's data paths and administrative paths are confined, not only the login step.
- Evidence mapping: link each map to the control it supports, and record how you tested it.
Ask your assessor which evidence they expect for access control on these hosts before you design the maps, so the same evidence can be produced without rework.
A map depends on SELinux being enforced with a policy that knows the SELinux users it names. Where SELinux is disabled, the map gives no confinement. Where it runs in permissive mode, the map may still set a context, but denials are logged rather than blocked, so the access decisions are not being enforced as designed. Permissive mode can show what enforcement would block, which makes it useful for tuning policy, but it is not a finished control.
- Disabled mode: no confinement is enforced, so the map offers no protection on that host.
- Permissive mode: denials are logged but not blocked, so treat it as a tuning stage.
- Policy mismatch: confirm that each SELinux user named in a map exists in the host's loaded policy, or logins may not behave as expected.
- Inventory: record the SELinux mode of each host alongside the maps, so no one assumes confinement that is absent.
Confirm the mode with getenforce and the loaded SELinux users with semanage user -l before you rely on any map on that host.
Setting up SELinux user maps step by step
This sequence takes a FreeIPA deployment from unconfirmed SELinux state to tested, host-scoped confinement for each login. Each step closes with a check, so the team knows what passed before moving on.
Confirm SELinux is enforcing on target hosts
The platform team checks each target host before any FreeIPA change is made. On the host, run
getenforceandsestatusas root and record the mode and loaded policy. A map only confines sessions when SELinux is enforcing, so any host reporting Permissive or Disabled needs its SELinux configuration corrected first. This step is done when every target host reports Enforcing and the policy type is recorded in the change log. Confirm the expected mode and policy with your distribution's SELinux documentation.Define SELinux users and host groups
The IAM or platform team decides which SELinux users apply to which login populations, such as staff, administrators or restricted users, and which hosts belong to each group. Confirm the SELinux user names available on your policy with the distribution documentation before you reference them. Use
ipa hostgroup-findandipa hostgroup-showto confirm that the host groups exist and contain the right machines. The step is complete when each planned SELinux user has a written owner, a host group and a list of member hosts.Create the SELinux user map
An IPA administrator creates the map with
ipa selinuxusermap-add, supplying the map name, the SELinux user and the host scope. Check the command's options againstipa help selinuxusermap-addon your FreeIPA version, because option names and the MLS range format have changed between releases. Scope the map to the host group defined earlier rather than to all hosts. Runipa selinuxusermap-showon the new map and confirm the SELinux user and host scope match the plan.Link the map to the HBAC rule
The map should only apply to logins that an HBAC rule already allows, so link it to that rule. Set the rule with the
--hbacruleoption when creating the map, or change it later withipa selinuxusermap-mod. Confirm the option name withipa help selinuxusermap-mod. The administrator then runsipa selinuxusermap-showagain and checks that the HBAC rule and the user and host categories appear as intended. The step is done when the output lists the expected HBAC rule and no unrelated rules.Test access decisions with hbactest
Before any user logs in, the administrator checks that the HBAC rule matches the intended combinations of user, host and service. Run
ipa hbactestwith the test user, the target host and the service name, such assshd, and read the result. Repeat for an account that should be denied, so the test shows both outcomes. Keep the commands and outputs with the change record, since they serve as evidence for later access reviews. The step is complete when the allowed and denied cases return the results written in the plan.Verify confinement on a test host
On a test host enrolled in the host group, a designated test account logs in over SSH. Run
id -Zin the session and compare the reported SELinux context with the SELinux user from the map. Also confirm that the account cannot perform actions its confined context should block, using a limited, pre-agreed test. If the context does not match, check the map's host scope, the HBAC match and whether SSSD on the host has picked up the change. The step is complete when the context matches the expected value and the failed test is blocked as planned.Roll out in stages and watch for denials
The team widens the host group in stages rather than applying the map across the whole estate at once. After each stage, review SELinux denials on the newly covered hosts with
ausearch -m AVCand check that legitimate work, such as application service accounts and admin tooling, still functions. Record any denial that needs a policy or map change. The rollout is complete when the last host group is covered and no unexpected denials remain in the review window agreed for the change. Keep the previous map configuration so it can be restored if needed.
How maps interact with HBAC and sudo options
HBAC decides whether a login is allowed at all, and the SELinux user map decides what that login runs as. These are two checks in sequence. The map only shapes an session that HBAC has already accepted, so it confines access but never creates it. In practice, the first question in any review is which HBAC rule matches the user, host and service. If that rule denies the login, the map is never applied to it. Confirm how the login stack for your distribution and services (SSH, console, su) orders these checks in the current FreeIPA documentation before you rely on that order in production.
Sudo SELinux options belong to the sudo rule, not to the map. They control the SELinux role and type that a sudo command runs under after the user is already logged in and has sudo rights. Because they sit inside a sudo rule, they only take effect when that rule matches the user and host and the user invokes sudo. A working setup therefore needs three things to line up: an HBAC rule that allowed the session, a user map that confined it, and a sudo rule with the intended SELinux option. Verify the option names and value format in the current sudo manual and the FreeIPA sudo rule documentation, and check them against the sudo version installed on your hosts.
The common mistake is treating a map as a grant. Teams add a map for a group of users, see that those users can reach a host, and conclude that the map opened the access. Others leave a broad allow_all HBAC rule in place and assume the map narrows it. Neither assumption holds. Test each combination with the HBAC test tool, then log in as a test user on a representative host and check the SELinux context of the resulting session. Keep a short matrix of user group, host group, HBAC outcome, expected SELinux user and sudo result, and rerun it after every change to a map, HBAC rule or sudo rule.
Security risks when confining users with maps
SELinux user maps confine users only if the rules around them agree. The risks below cluster around how maps interact with HBAC, sudo, host drift and logging, so each card names a control and a recurring check.
Unconfined type granted by accident
A map that points a user at unconfined_u or a broadly privileged SELinux user removes the confinement the map was meant to add. This often happens when a map is copied from a host that needed looser settings. Keep the default SELinux user for general users, and review every map whose target is not a confined user. Check that the ipa selinuxusermap-find output still matches the policy you approved, and that no one has added a higher privilege map to a broad user group.
Maps that conflict with access rules
A map only sets the SELinux context after login, so it does not decide who may log in. An HBAC rule that allows a group the map does not cover can leave users with a default context, and a map that targets a group without an HBAC allowance gives a false sense of control. Test each map with ipa hbactest alongside the HBAC rules it depends on, and review both sets together whenever either changes.
Sudo bypassing confinement
Sudo rules can run commands in a different SELinux context, so an administrator who can sudo to a broad command may leave the confined context entirely. Review sudo rules that set SELinux role or type options alongside the maps they can reach, and restrict who can use sudo on confined hosts. Confirm, against your own sudo configuration and the SELinux documentation for your distribution, which sudo options take effect in your environment.
Drift between hosts
Maps are defined centrally, but hosts are enrolled, reinstalled and moved between host groups over time. A host that was missed by a map, or that was enrolled with an older policy, can run with a different confinement than its peers. Compare the host groups each map targets against the current host inventory on a fixed schedule, and check SELinux mode on sample hosts after every enrollment wave.
Audit gaps in confinement changes
If changes to maps, HBAC rules and sudo rules are not recorded with who made them and when, a confinement weakening can go unnoticed until an incident. Confirm which FreeIPA administrative events your deployment logs and where they go, and keep a dated export of map definitions. Review changes to maps against the change tickets that justified them each quarter.
Testing confinement without locking people out
Test every SELinux user map on a non-production host before it reaches a server that people depend on. The point is to confirm two things at once: that the intended user lands in the intended SELinux user, and that HBAC still lets them in. A map that confines correctly but blocks the login path leaves administrators locked out, so both checks belong in the same test pass. Start by building a test host enrolled in your staging IPA domain, then assign it the same host group that production uses for the map. If your staging domain does not mirror production group membership, the test proves nothing about production.
Once the map is applied to the test host, log in as a representative user and run id -Z in the session to read the SELinux context. Compare the result with the expected user, such as staff_u for a member of an administrators group, and check that the context matches the role you intended. Then use ipa hbactest against the same user, host and service combinations that real logins will use, including SSH and any console or sudo service your rules cover. Record which combinations you tested and the result of each. Ask your team to confirm the exact service names in your environment, because a rule that matches only sshd will not cover a different PAM service.
Keep a rollback path open before you change anything on production. Know which map or HBAC rule you changed, how to disable or revert it through the IPA CLI or web UI, and who has the rights to do it at 2 a.m. Also confirm that a local administrator account with a known working login exists on each affected host, because it is the fallback if the map or HBAC change blocks every remote login. Roll out to one host or a small host group first, and keep the rest of the fleet on the previous policy until the first group has run through its normal login patterns. Treat the test record as part of the change record. Store the test case list, the commands and their outputs, the tester, the date, and the FreeIPA version on the test host, alongside the approval for production. Auditors who check access control will ask what was tested and when, and a dated record answers that without reconstruction. Re-run the same cases after any FreeIPA upgrade or any change to host groups, since those can alter the result without anyone touching the map itself.
Limits to confirm in your environment
SELinux user maps depend on details that differ between hosts, distributions and FreeIPA deployments. The cards below list the items to verify before you write any map or sudo rule, because a wrong assumption at any one of them can leave a host confined differently from what your policy says.
SELinux policy and mode per host
Confirm which SELinux policy each host runs (targeted or MLS), whether it is enforcing, permissive or disabled, and whether that matches across the hosts a single map will cover. A map that assigns staff_u to a host whose policy does not define that user, or to a host in permissive mode, gives you a result that looks correct in configuration but does not confine anything in practice. Record the policy and mode per host group before you design maps.
SELinux user support by distribution
Confirm that each SELinux user you plan to map, such as staff_u, user_u or sysadm_u, exists in the policy shipped on your distributions and on the versions you run. Support differs between policy packages, so do not assume that a user name taken from one distribution exists on another. Ask the policy maintainers or your distribution vendor for the list of users in the packaged policy, and test each one on a representative host.
Behavior on non-RHEL clients
Confirm how SSSD and the SELinux user map handling on each non-RHEL client compare with your reference RHEL-family hosts before you apply a map there. The FreeIPA documentation you rely on is written around specific platforms, so verify the client version, the SSSD version and the local SELinux tooling on every distribution you enroll. Where behavior is not confirmed, keep those hosts out of the first map and test them separately.
FreeIPA server and client versions
Record the FreeIPA server version and the client version on every host before you design SELinux user maps, since map handling and related features can change between releases. Recent 4.x releases have added and fixed behavior in areas that touch authentication and access, so a deployment on an older or unpatched release may behave differently from the documentation you are reading. Confirm the exact versions and check the release notes for changes that affect your build.
Sudo SELinux options on each host
Confirm that the sudo version on each target host supports the SELinux-related options you plan to use in sudo rules, and that the rules reach the hosts through the same SSSD and sudo integration you have tested. Sudo options that are missing from an older build can be ignored or rejected, which can silently widen or narrow the privileges a user receives. Test the exact option set on each sudo version in your fleet.
Interaction with HBAC and login paths
Confirm which login services, such as SSH, console, graphical login and cron, reach each host, and which of them your HBAC rules allow, before you rely on a map to confine a session. A map only applies to sessions that pass HBAC and reach the SELinux login path, so a service that bypasses the expected path can run a user under a different context. Write down each service and the test you will run for it.
Questions buyers ask about SELinux user maps
What drives the cost of setting up FreeIPA SELinux user maps?
The cost depends on how many host groups need confinement, how many SELinux user roles you map to each group, and how much of your existing HBAC and sudo design has to change first. Most of the effort is analysis and testing rather than typing rules: you must learn which accounts log in where, what they do after login, and which SELinux context each workload expects. Ask any partner for a quote that splits work into discovery of current access, map design, test host preparation, enforcement and handover. Each line should name who performs it and what they deliver. DeployOpen plans and delivers fixed-scope work agreed in writing, so the written scope is where these components are priced.
How long does a pilot of SELinux user maps take?
The pilot length is set by the number of host groups in the pilot, the number of distinct user populations, and how quickly your team can provide test hosts and approve changes. Pilots slow down when application owners need to confirm that services still run under the mapped context, and when test results have to go through your change control. No duration is given here because the time varies widely between environments. Ask for a timeline tied to specific host groups and exit criteria, such as a set of login and privileged-command tests passing on each pilot host. Your own estimate from your change calendar is a useful check on any proposal.
What does our team need to provide for SELinux user maps?
Your team needs three things: someone who understands SELinux policy and contexts well enough to judge whether a confined user can still do their job, a set of representative test hosts that mirror production builds and services, and a change control path that accepts staged rollouts to host groups. The FreeIPA side also needs an administrator who can review HBAC and sudo rules, because SELinux user maps are linked to those rules. Plan time for application owners to confirm their workloads. Confirm each requirement in writing before work starts, including who approves changes to production hosts and how rollback is handled.
Can our internal team set up SELinux user maps without a partner?
Yes, if your team already runs FreeIPA and has SELinux expertise, the configuration itself is not large. The harder part is designing confinement for real workloads and proving that legitimate access is not blocked. Teams often do well when they have one engineer owning FreeIPA, one owning host hardening, and time set aside for testing. A partner is most useful when those skills are thin, when the rollout must cover many host groups quickly, or when you need independent test evidence for an assessment. Whichever route you take, keep the test cases and the record of each enforcement step so the decision can be reviewed later.
What ongoing work recurs after SELinux user maps go live?
After go-live, the recurring work is reviewing new hosts and host groups, updating maps when applications or users change roles, and re-running login and privilege tests after operating system and FreeIPA upgrades. You also need to review denials that appear in audit logs, decide whether each one reflects a real need or an overly tight map, and record the outcome. Sudo SELinux options and HBAC rules may need adjustment when administrators change their duties. Ask any partner to define which of these tasks are included in a support retainer and which remain with your team, because they recur for as long as the environment does.
What is the risk of confining users with SELinux maps too early?
The main risk is locking out legitimate users or breaking services that depend on specific SELinux contexts. Access that worked before can stop after enforcement, which affects administration, batch jobs and support staff. Reduce the risk by running tests on representative hosts, enforcing one host group at a time, and keeping a documented rollback. Confirm with your change board how emergency access will work during an incident, because this must remain available while maps are being refined.
Do SELinux user maps need an existing FreeIPA deployment first?
Yes. SELinux user maps are a FreeIPA feature, so the FreeIPA deployment, its client enrollment and its HBAC and sudo rules must already be in place. Your existing access design determines where maps add value and where they conflict with current rules. Review those rules before adding maps, and confirm the FreeIPA version you run against the feature documentation for that release.
How DeployOpen scopes and delivers SELinux user map work
DeployOpen plans, implements, documents and supports FreeIPA on servers you control, including the SELinux user maps, HBAC links and sudo options that confine users on each host. Work starts from a written scope that names the host groups, SELinux users and test cases your organization needs before any rule changes in production.
How we scope
- Inventory which host groups, operating systems and HBAC rules the SELinux user maps must cover.
- Agree in writing which SELinux users, such as staff_u, are assigned to which user groups and hosts.
- Record the sudo SELinux options, roles and exceptions that are in scope and those that are not.
- Confirm the FreeIPA version, client versions and change windows with your team before estimating work.
How we build
- Create SELinux user maps in a staging FreeIPA environment and link them to the agreed HBAC rules.
- Run hbactest and login tests for each user, host and service combination before enforcement.
- Verify confinement on representative clients, including the SELinux context shown after login.
- Keep configuration and test cases in version-controlled files so changes can be reviewed and repeated.
How we hand over
- Deliver a written record of each map, its linked rules, its target hosts and its test results.
- Document the rollback steps for each change, including how to remove a map without locking out administrators.
- Walk your administrators through how to add a user or host to a map and retest it.
- Provide a runbook for checking confinement after client enrollment or host renaming.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if your team wants help after handover.
- Review map and HBAC changes as FreeIPA releases and client distributions change over time.
- Ask for a quote from the written scope, which sets out what is one-time work and what recurs.
- Confirm with your security and compliance leads which evidence they need before any independent assessment.
