Hide Forgot
Description of problem: Users connecting via xrdp always inherit the context from the xrdp-sesman service. I suspect this problem happens universally, but I've only tested it on x86_64 hardware running RHEL 7.x Version-Release number of selected component (if applicable): OS: RHEL 7 (kernel 3.10.0-327.28.3.el7.x86_64) xrdp: version 0.9.0 Release 4.3l7 tigervnc: version 1.3.1 Release 4.el7_2 How reproducible: completely Steps to Reproduce: 1. connect to a host via Microsoft's mstsc 2. in a shell run 'id -Z' Actual results: system_u:system_r:unconfined_service_t:s0 Expected results: The default context, which is unconfined_u:unconfined_r:unconfined_t:s0 Note that an SSH session gets this context. Additional info: * Under RHEL 6.8, it was possible to get the default context by using pam_selinux before the included password-auth in the PAM module for xrdp-sesman. That strategy doesn't work for RHEL 7.x; instead, when pam_selinux is in the PAM module, the connection always fails. * Debug from pam_selinux shows that it's setting the key creation context to the expected value. Immediately following this pam_unix reports session closed. * On RHEL 6.8 I essentially copied the sshd PAM module and then edited it a bit. I tried the same approach on RHEL 7, with no luck -- could not connect. * What I would really like to do is run 'normal' users under user_u and admins under sysadm_u. I was never able to get this to work for xrdp, regardless of the OS (6 or 7) or how I arranged the login mapping file or the xrdp-sesman PAM module. However, sshd seemed to handle different default mappings as well as user-specific mappings for selinux logins without a problem (I never messed with its PAM stuff). For example, under RHEL 6.8, adding a mapping for myself to sysadm_u worked for ssh, but caused the xrdp session to revert back to system_u. * The above situation makes me think that what's lacking here is a specific selinux policy for xrdp, but building such a policy is (currently) beyond my skill level, and in any case I don't currently have the time.
please report this against selinux package, thank you.
We could try to run the xrdb process as xdm_t or local_login_t or sshd_t, which could get the transition to happen correctly. You could do a quick experiment on this. chcon -t xdm_exec_t PATHTO/xrdb Then restart the service using systemd. Now see of the xrdb service is running as xdm_exec_t. You might need to do this in permissive mode. Now connect to the xrdb service and see what the context of the user ends up with. If the user ends up running as unconfined_t or user_t, you are most of the way there. If there are AVC's we can look at them and see if we can easily add them to the login domains.
If this works we can also label xrdb correctly in selinux-policy. Now this is all my assumption that xrdb is really a fancy remote login program.
*** This bug has been marked as a duplicate of bug 1421573 ***
I ran into this on F30, unfortunately RHEL8 doesn't have xrdp RPMs currently. The duplicate mark above is incorrect, bug 1421573 has nothing to do with this. Daniel's suggestion above is almost correct, you can label xrdp-sesman as xdm_exec_t and it will run as xdm_t, but the xrdp pam config does not have the selinux parts, this needs to be added to pam.d/xrdp-sesman: # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_loginuid.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open env_params *above* the session line that is already there. Additionally, xdm_t would need some additional permissions. xrdp-sesman tries to write to etc_t and runs startwm.sh from the users home directory. So either those rules will have to be added to xdm's policy or a new policy for xrdp-sesman will have to be written, if that is written the selinux contexts/users files will need to be updated. In summary 1) this isn't a duplicate 2) it isn't fixed in F30, 3) some additional work needs to be done to make this work on real systems.
Have you tried running with gdm-password in /etc/pam.d/xrdp-sesman (i.e. the commented out bits put in by the package)? I don't have SELinux issues when trying to run xrdp/Gnome on F30 EC2 with SELinux enabled.
If you don't relabel xrdp-sesman and add the selinux pam your session will be running as unconfined_service_t which may work for you, but is decidedly not what I'm going for. I need my user sessions to be correctly labeled for that particular user (we aren't using unconfined, we have users with explicit user domains).