Description of problem: sshd (temporarily) runs itself in the unconfined_t SELinux security domain if you log in as root with a stock fedora system. Version-Release number of selected component (if applicable): any How reproducible: cat >> mytest <<EOF policy_module(mytest, 1.0.0) gen_require(\` type unconfined_t; ') auditallow unconfined_t self:process setexec; EOF make -f /usr/share/selinux/devel/Makefile mytest.pp sudo semodule -i mytest.pp log in as root with ssh look in the audit.log for avc granted message You should see a granted message. See the comm="" field of the message. It should say "sshd" See the scontext="" field of them essage. It should say "unconfined_i:unconfined_r:unconfined_t:s0-s0:c1023" This proves that sshd atleast for a short while runs in the SELinux unconfined_t security domain Actual results: sshd runs unrestricted/unprotected Expected results: sshd runs restricted/protected
You can see this also in pstree. I don't think this is a bug, but feature. Even if you run ssh with non-root user, you get such pstree: ├─sshd,`system_u:system_r:sshd_t:s0-s0:c0.c1023' -D │ └─sshd,`system_u:system_r:sshd_t:s0-s0:c0.c1023' │ └─sshd,`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023' │ └─bash,`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023' │ └─pstree,`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023' -aZh which can be explained this way: ->(daemon) ->(privileged monitor) ->(user restricted child) ->(bash ...) which is comparable to normal login session, but you miss the sshd server and monitor below: ├─login,`system_u:system_r:local_login_t:s0-s0:c0.c1023' │ └─bash,`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023' │ └─pstree,`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023' -aZh You have got "privileged" monitor, but child process is restricted by target user access rights. If it is root, you can't restrict it anyway. It is just unrestricted session.
Yes, to change the context for the user session, the sshd process must be unrestricted.