Bug 1376401

Summary:	Cannot control selinux context for xrdp connections
Product:	Red Hat Enterprise Linux 7	Reporter:	RW Shore <rws228>
Component:	selinux-policy	Assignee:	Lukas Vrabec <lvrabec>
Status:	CLOSED DUPLICATE	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	bojan, dwalsh, itamar, joshua.brindle, lvrabec, mgrepl, mmalik, plautrba, ssekidde
Target Milestone:	rc	Keywords:	Reopened
Target Release:	7.5
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-06-12 13:21:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description RW Shore 2016-09-15 11:14:37 UTC

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.

Comment 1 Itamar Reis Peixoto 2016-10-29 01:27:49 UTC

please report this against selinux package, thank you.

Comment 2 Daniel Walsh 2018-04-27 10:21:22 UTC

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.

Comment 4 Daniel Walsh 2018-04-27 10:31:34 UTC

    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.

Comment 5 Lukas Vrabec 2018-06-12 13:21:55 UTC


*** This bug has been marked as a duplicate of bug 1421573 ***

Comment 6 Joshua Brindle 2019-08-07 15:26:58 UTC

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.

Comment 7 Bojan Smojver 2019-08-09 23:24:39 UTC

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.

Comment 8 Joshua Brindle 2019-08-10 01:05:37 UTC

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).