Incorrect SELinux context on ptys

[duckfez]

On RHEL-like Linuxes with SELinux in enforcing mode and the RHEL "targeted" policy, pty library does not set the correct selinux context on pty devices. The expected context is user_devpts_t and the assigned context to the pty is devpts_t. Connecting to the same host using OpenSSH will result in the pty devices having the correct selinux context.

There is some code in OpenSSH-portable that demonstrates how they derive the correct context and apply it - https://github.com/openssh/openssh-portable/blob/4a5590a5ee47b7dfd49773e9fdba48ad3089fe64/openbsd-compat/port-linux.c#L136

This appears to be an underlying issue for both https://github.com/aws/amazon-ssm-agent/issues/498 and https://github.com/gravitational/teleport/issues/19871

[kr]

Is there a way for client code to set the selinux context? At first glance, it seems like something package pty shouldn't interfere with.

How can we know what the correct selinux context would be for each different application? Or if the correct selinux context is always the same, why is it configurable at all?

[creack]

indeed, my knowledge of SELinux is very limited, but if the client code can set the context, doesn't it defeat the purpose?

[creack]

Would you have a self-contained code I could use to reproduce the issue by any chance?

[duckfez]

My selinux knowledge is weak too. I don’t have a simple test case for this yet but I will try.

From reading the OpenSSH code they rely on some helper funcs from libselinux. There is a cgo binding for those functions. Would a cgo requirement be a problem for you?

[creack]

A lot of projects use this lib, which is currently working without cgo. Introducing cgo would likely cause issues, requiring people using the lib to explicitly disable it in case they run in an env without the libc, and it would cause some behavior differences between cgo and not cgo. tl;dr I would rather avoid it, having a way to reproduce the issue would allow for further investigation, see if we can do without it.

[creack]

I installed a VM with rhel9 and tried to reproduce the issue, but without success. I used the sample code from the readme to run a shell in a pty. The SE context looks correct and chronyc works fine.

# Via SSH.
[vagrant@rhel9 foo]$ getenforce
Enforcing
[vagrant@rhel9 foo]$ ls -lZ $( tty )
crw--w----. 1 vagrant tty unconfined_u:object_r:user_devpts_t:s0 136, 0 Jan 12 01:36 /dev/pts/0
[vagrant@rhel9 foo]$ chronyc sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^- time.skylineservers.com       2   6   377     4  +8442us[+8442us] +/-   42ms
^- pacific.latt.net              3   6   377     5  +8725us[  +22ms] +/-  100ms
^* time.cloudflare.com           3   6   377     5    +12ms[  +25ms] +/-   23ms
^- user-24-214-53-97.knolog>     2   6   377     3    +12ms[  +12ms] +/-   45ms

# Running a shell using the pty lib.
[vagrant@rhel9 foo]$ ./foo
[vagrant@rhel9 foo]$ getenforce
Enforcing
[vagrant@rhel9 foo]$ ls -lZ $( tty )
crw--w----. 1 vagrant tty unconfined_u:object_r:user_devpts_t:s0 136, 1 Jan 12 01:36 /dev/pts/1
[vagrant@rhel9 foo]$ chronyc sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^- time.skylineservers.com       2   6   377    17  +8442us[+8442us] +/-   42ms
^- pacific.latt.net              3   6   377    18  +8725us[  +22ms] +/-  100ms
^* time.cloudflare.com           3   6   377    18    +12ms[  +25ms] +/-   23ms
^- user-24-214-53-97.knolog>     2   6   377    16    +12ms[  +12ms] +/-   45ms

NOTE: In case running ssh sets the right context so running the pty shell within ssh causes it to work, I also tried directly with virtualbox without SSH and got the same result.

[duckfez]

@creack Well sir, this is awkward. Having seen the same problem in two different upstream projects that use your lib, I was sure I'd found the common cause. Allow me to do some more investigation - this might be a RHEL7 specific oddity and if so there's NO reason to follow up on it because RHEL7 is so close to EOL.

Is the source to your foo program in the pty repo?

[creack]

When I have some time, I'll try with RHEL7/

The foo program is the sample shell from the readme: https://github.com/creack/pty#shell

[creack]

Closing as it doesn't seem to be related to the lib.