Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionLenny Szubowicz
2017-11-16 21:52:49 UTC
Description of problem:
Selinux prevents login via a USB port that's configured as a serial console, e.g. /dev/ttyUSB0
Error from journalctl:
Nov 16 15:08:23 intel-glk-01.ml3.eng.bos.redhat.com agetty[1599]: /dev/ttyUSB0: cannot open as standard input: Permission denied
From /var/log/audit/audit.log
type=SERVICE_START msg=audit(1510861554.753:445): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=serial-getty@ttyUSB0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1510861555.022:446): avc: denied { read write } for pid=1599 comm="agetty" name="ttyUSB0" dev="devtmpfs" ino=15451 scontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usbtty_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1510861555.022:446): arch=c000003e syscall=2 success=no exit=-13 a0=7ffe47edf2c0 a1=902 a2=0 a3=7ffe47ede600 items=0 ppid=1 pid=1599 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="agetty" exe="/usr/sbin/agetty" subj=system_u:system_r:getty_t:s0-s0:c0.c1023 key=(null)
The ability to use a USB port as the system's serial console is becoming increasingly important. We are seeing more small systems where either there is no serial port or the serial port just does not work. However, such systems usually have many USB ports.
One obstacle to using a USB port with a USB-to-serial adapter cable is that the default RHEL 7.x SElinux policy does not allow agetty to initiate a login via that serial port.
Version-Release number of selected component (if applicable):
RHEL-7.5-20171114.n.0
How reproducible: 100%
Steps to Reproduce:
1. connect USB-to-serial cable from system under test to another system running putty or minicom
2. add to kernel command line: console=ttyUSB0,115200n81
3. systemctl enable serial-getty
4. add ttyUSB0 as last line to /etc/securetty (don't know if this is really needed)
5. reboot
Actual results:
1. Kernel boot messages appear via ttyUSB0 as expected
2. No login prompt via ttyUSB0 and agetty error in /var/log/audit/audit.log
Expected results:
1. Kernel boot messages appear via ttyUSB0
2. Login prompt and able to login to ttyUSB0 console
Additional info:
agetty works and I'm able to login if either I:
1. Disable selinux on the kernel command line selinux=0
2. Or, I change the SElinux type of the /dev/ttyUSB0 device to match /dev/ttyS0
[root@localhost ~]# ls -Z /dev/ttyS0
crw--w----. root tty system_u:object_r:tty_device_t:s0 /dev/ttyS0
[root@localhost ~]# ls -Z /dev/ttyUSB0
crw--w----. root tty system_u:object_r:usbtty_device_t:s0 /dev/ttyUSB0
[root@intel-glk-01 ~]# chcon -t tty_device_t /dev/ttyUSB0
[root@intel-glk-01 ~]# ls -Z /dev/ttyUSB0
crw--w----. root tty system_u:object_r:tty_device_t:s0 /dev/ttyUSB0
Although work-around #2 is more targetted, it is not persistent across reboots.
If allowing login via ttyUSB0 by default raises security concerns, could you add an semanage boolean which would allow a system admin the option to enable this persistently as needed?
Finally, note that this is the same problem which was reported against Fedora 25 in BZ 1307443
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2018:0763
Description of problem: Selinux prevents login via a USB port that's configured as a serial console, e.g. /dev/ttyUSB0 Error from journalctl: Nov 16 15:08:23 intel-glk-01.ml3.eng.bos.redhat.com agetty[1599]: /dev/ttyUSB0: cannot open as standard input: Permission denied From /var/log/audit/audit.log type=SERVICE_START msg=audit(1510861554.753:445): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=serial-getty@ttyUSB0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' type=AVC msg=audit(1510861555.022:446): avc: denied { read write } for pid=1599 comm="agetty" name="ttyUSB0" dev="devtmpfs" ino=15451 scontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usbtty_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1510861555.022:446): arch=c000003e syscall=2 success=no exit=-13 a0=7ffe47edf2c0 a1=902 a2=0 a3=7ffe47ede600 items=0 ppid=1 pid=1599 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="agetty" exe="/usr/sbin/agetty" subj=system_u:system_r:getty_t:s0-s0:c0.c1023 key=(null) The ability to use a USB port as the system's serial console is becoming increasingly important. We are seeing more small systems where either there is no serial port or the serial port just does not work. However, such systems usually have many USB ports. One obstacle to using a USB port with a USB-to-serial adapter cable is that the default RHEL 7.x SElinux policy does not allow agetty to initiate a login via that serial port. Version-Release number of selected component (if applicable): RHEL-7.5-20171114.n.0 How reproducible: 100% Steps to Reproduce: 1. connect USB-to-serial cable from system under test to another system running putty or minicom 2. add to kernel command line: console=ttyUSB0,115200n81 3. systemctl enable serial-getty 4. add ttyUSB0 as last line to /etc/securetty (don't know if this is really needed) 5. reboot Actual results: 1. Kernel boot messages appear via ttyUSB0 as expected 2. No login prompt via ttyUSB0 and agetty error in /var/log/audit/audit.log Expected results: 1. Kernel boot messages appear via ttyUSB0 2. Login prompt and able to login to ttyUSB0 console Additional info: agetty works and I'm able to login if either I: 1. Disable selinux on the kernel command line selinux=0 2. Or, I change the SElinux type of the /dev/ttyUSB0 device to match /dev/ttyS0 [root@localhost ~]# ls -Z /dev/ttyS0 crw--w----. root tty system_u:object_r:tty_device_t:s0 /dev/ttyS0 [root@localhost ~]# ls -Z /dev/ttyUSB0 crw--w----. root tty system_u:object_r:usbtty_device_t:s0 /dev/ttyUSB0 [root@intel-glk-01 ~]# chcon -t tty_device_t /dev/ttyUSB0 [root@intel-glk-01 ~]# ls -Z /dev/ttyUSB0 crw--w----. root tty system_u:object_r:tty_device_t:s0 /dev/ttyUSB0 Although work-around #2 is more targetted, it is not persistent across reboots. If allowing login via ttyUSB0 by default raises security concerns, could you add an semanage boolean which would allow a system admin the option to enable this persistently as needed? Finally, note that this is the same problem which was reported against Fedora 25 in BZ 1307443