Sysadm_u still ssh after setting ssh_sysadm_login off

Rocky Linux Help & Support
1

Hello,

I mapped a user called user05 to sysadm_u SELinux login, and i set the boolean ssh_sysadm_login off.

But the user can still access via ssh.

[root@srv-rocky srv-admin]# getsebool ssh_sysadm_login

ssh_sysadm_login --> off

[root@srv-rocky srv-admin]# sudo semanage login -a -s sysadm_u user05

Login mapping for user05 is already defined, modifying instead

[root@srv-rocky srv-admin]# sudo semanage user -l | grep sysadm_u

sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r

[root@srv-rocky srv-admin]# semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          unconfined_u         s0                   *

root                 unconfined_u         s0-s0:c0.c1023       *

user05               sysadm_u             s0-s0:c0.c1023       *

user06c              staff_u              s0-s0:c0.c1023       *

user07               staff_u              s0-s0:c0.c1023       *

user08               guest_u              s0                   *

user10               user_u               s0                   *

piCO@pICO-MacBook ~ % ssh user05@192.168.1.107

user05@192.168.11.107's password: 

Last login: Sat Jun 20 18:07:42 2026 from 192.168.1.104

[user05@srv-rocky ~]$ id -Z

sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
2

I’m speculating that “off” means the rule is disabled and “on” would enable it.

4

Are you part of the OP’s team? Did turning the variable “on” result in the outcome you were seeking?
There aren’t many who are delving into the workings of selinux so you are as much the experts as any of the rest of us. So posting the results, good or bad, is useful information that may help others.

5

Hello,

Apologies for the delay; I was unavailable over the last few days.

When the rule is set on, users mapped to the system_u SELinux user should be permitted to access the system via SSH. When the rule is set off, SSH access should be denied for those users.

6

You’ve tested this then with selinux in enforcing mode?

7

yes, SELinux is enforced.

8

In my tests last month I always had to set this boolean to on when I wanted to log in as a sysadm_u user. Can you tell us which version of Rocky Linux you’re using?

And a small correction, you probably meant “sysadm_u”, not “system_u” here:

9

I’ve been able to reproduce this issue on Rocky 10 and Alma 10. There is no issue on Rocky 9, 8 and CentOS 7. So I misremembered that I always had to set this boolean to log in, probably I got a failure on 2 different systems and then I just set the boolean on all the others.

There are some interesting differences in the SELinux denial entries between the OS versions but I’m not a SELinux expert and at the moment I don’t have the time to investigate further.

This is the full denial entry on Rocky 10 during SSH login (which succeeds anyway):

time->Fri Jun 26 14:47:25 2026
type=PROCTITLE msg=audit(1782485245.988:293): proctitle=737368642D73657373696F6E3A2074657374736573797361646D31205B707269765D
type=SYSCALL msg=audit(1782485245.988:293): arch=c000003e syscall=1 success=yes exit=42 a0=8 a1=5644db257850 a2=2a a3=0 items=0 ppid=1728 pid=1764 auid=1001 uid=1001 gid=1006 euid=1001 suid=1001 fsuid=1001 egid=1006 sgid=1006 fsgid=1006 tty=(none) ses=5 comm="sshd-session" exe="/usr/libexec/openssh/sshd-session" subj=sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1782485245.988:293): avc:  denied  { dyntransition } for  pid=1764 comm="sshd-session" scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tclass=process permissive=1

This is the denial on Rocky 9 during SSH login (which fails):

time->Fri Jun 26 15:14:17 2026
type=PROCTITLE msg=audit(1782486857.166:228): proctitle=737368642D73657373696F6E3A2074657374736573797361646D31205B707269765D
type=SYSCALL msg=audit(1782486857.166:228): arch=c000003e syscall=1 success=no exit=-13 a0=9 a1=55d18afefd90 a2=2a a3=0 items=0 ppid=1408 pid=1424 auid=1001 uid=1001 gid=1006 euid=1001 suid=1001 fsuid=1001 egid=1006 sgid=1006 fsgid=1006 tty=(none) ses=5 comm="sshd-session" exe="/usr/libexec/openssh/sshd-session" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1782486857.166:228): avc:  denied  { dyntransition } for  pid=1424 comm="sshd-session" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tclass=process permissive=0
10

The context is different, and on one you’ve got permissive = true

11

That’s true, these are the main differences. On Rocky 10 the domain is sshd_session_t and permissive is 1. On Rocky 9 the domain is sshd_t and permissive is 0. On Rocky 10:

# semanage permissive -l

Builtin Permissive Types 

dhcpc_hook_t
systemd_hibernate_resume_t
sshd_session_t
sshd_auth_t
systemd_zram_generator_t
systemd_import_generator_t
virtqemud_t
coreos_liveiso_autologin_generator_t
systemd_generic_generator_t
virtvboxd_t
coreos_boot_mount_generator_t
qgs_t
systemd_nfs_generator_t
systemd_pcrlock_t
systemd_oomd_t
virtstoraged_t
coreos_installer_generator_t
systemd_tpm2_generator_t
coreos_sulogin_force_generator_t
virtsecretd_t
systemd_mountfsd_t
redfish_finder_t
bootupd_t

Because sshd_session_t is permissive, violations are logged but not enforced.

12

Hello,

yes sysadm_u,

whatevert setting the ssh_sysadm_login on or off, user05 can still access via ssh.

[root@srv-rocky srv-admin]# semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          unconfined_u         s0                   *

root                 unconfined_u         s0-s0:c0.c1023       *

user05               sysadm_u             s0-s0:c0.c1023       *

user06c              staff_u              s0-s0:c0.c1023       *

user07               staff_u              s0-s0:c0.c1023       *

user08               guest_u              s0                   *

user09               staff_u              s0-s0:c0.c1023       *

user10               user_u               s0                   *

[root@srv-rocky srv-admin]# sestatus 

SELinux status:                 enabled

SELinuxfs mount:                /sys/fs/selinux

SELinux root directory:         /etc/selinux

Loaded policy name:             targeted

Current mode:                   enforcing

Mode from config file:          enforcing

Policy MLS status:              enabled

Policy deny_unknown status:     allowed

Memory protection checking:     actual (secure)

Max kernel policy version:      33

[root@srv-rocky srv-admin]# semanage boolean -l | grep sysadm

ssh_sysadm_login               (on   ,   on)  Allow ssh to sysadm login

sysadm_exec_content            (on   ,   on)  Allow sysadm to exec content

xdm_sysadm_login               (off  ,  off)  Allow xdm to sysadm login
13

Yes, it’s caused by the sshd_session_t domain being permissive on RHEL 10 and its derivatives. I thought that the semanage permissive commands could be used to change this configuration, but apparently it’s not possible. Quoting from man semanage-permissive:

Please note that this command can make any domain permissive, but can only remove the permissive property from domains where it was added by semanage permissive (“semanage permissive -d” can only be used on types listed as “Customized Permissive Types” by “semanage permissive -l”).

14

Hello,

I tried to remove the sshd_session_t from the permissive liste but it fail the error bellow.

[root@srv-rocky srv-admin]# semanage permissive -d sshd_session_t
libsemanage.semanage_direct_remove_key: Unable to remove module permissive_sshd_session_t at priority 400. (No such file or directory).
FileNotFoundError: No such file or directory

[root@srv-rocky srv-admin]# semanage permissive -d sshd_auth_t
libsemanage.semanage_direct_remove_key: Unable to remove module permissive_sshd_auth_t at priority 400. (No such file or directory).
FileNotFoundError: No such file or directory
15

Of course, it’s just as the man page says. You can’t delete built-in permissive types. I think this change can only be made in the source code, it would require rebuilding SELinux RPM packages from source and it’s not easy to do. If you absolutely must have this rule enforced, I suggest installing Rocky Linux 9, not 10. Hopefully these new policies will be well-tested and set to enforcing by the time RHEL 11 is released.