1749954 – root (or others) confined to sysadm_u or staff_u cannot run newaliases

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.

Bug 1749954 - root (or others) confined to sysadm_u or staff_u cannot run newaliases

Summary: root (or others) confined to sysadm_u or staff_u cannot run newaliases

Keywords:
Status:	CLOSED WONTFIX
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	selinux-policy
Sub Component:
Version:	7.7
Hardware:	All
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Lukas Vrabec
QA Contact:	Milos Malik
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2019-09-06 21:24 UTC by Mason Loring Bliss
Modified:	2019-09-12 09:02 UTC (History)
CC List:	7 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Clones:	1750405 (view as bug list)
Environment:
Last Closed:	2019-09-12 09:02:08 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description Mason Loring Bliss 2019-09-06 21:24:22 UTC

Description of problem:

On a system with root confined to sysadm_u or staff_u, newaliases(1) fails when
postfix is installed.

[root@mlb-rhel7 ~]# ls -laZ /usr/sbin/sendmail.postfix 
-rwxr-xr-x. root root system_u:object_r:sendmail_exec_t:s0 /usr/sbin/sendmail.postfix

From the customer:

------------------------------------------------------------------------------
# sesearch -A -t sendmail_exec_t -s user_mail_t -p entrypoint
Found 2 semantic av rules:
   allow user_mail_domain mta_exec_type : file { ioctl read getattr lock map execute execute_no_trans entrypoint open } ; 
   allow user_mail_t sendmail_exec_t : file { ioctl read getattr lock map execute execute_no_trans entrypoint open } ; 

writing to the aliases-file is fine, but once you run newaliases to update the database the context transits to user_mail_t which is not allowed to write to /etc/aliases.db..
------------------------------------------------------------------------------


Steps to Reproduce:

[root@repo ~]# newaliases
postalias: fatal: open /etc/aliases.db: Permission denied


Additional info:

It would be useful having more extensive documentation for use of confined
users, including the particular intent of each role.

Comment 2 Fredrik Eriksson 2019-09-09 07:24:08 UTC

Some additional information/clarification:

The "newaliases"-command is a symlink that eventually resolves to the sendmail.postfix binary, which is labeled as 'sendmail_exec_t'. When executed in the 'sysadm_t' context the process will transition to the 'user_mail_t' context, which is not allowed to write to files labeled with 'etc_aliases_t', which is why the command fails.

Two possible solutions:
 - add a rule to allow 'user_mail_t' to write to 'etc_aliases_t'. This is the fastest and easiest solution, but may be too permissive.
 - ensure 'sysadm_t' does not transition to 'user_mail_t' (by using another wrapper and/or context or some other creative way).

Comment 3 Milos Malik 2019-09-09 10:49:03 UTC

$ id -Z
sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
$ su
Password: 
# id
uid=0(root) gid=0(root) groups=0(root) context=sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
# newaliases
postalias: fatal: open /etc/aliases.db: Permission denied
#

Following SELinux denial appeared in enforcing mode:
----
type=PROCTITLE msg=audit(09/09/2019 06:44:44.467:377) : proctitle=postalias hash /etc/aliases 
type=SYSCALL msg=audit(09/09/2019 06:44:44.467:377) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x5620c6cc64a0 a1=O_RDWR a2=0x1a4 a3=0x3 items=0 ppid=9103 pid=9115 auid=sysadm-user uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=4 comm=postalias exe=/usr/sbin/postalias subj=sysadm_u:sysadm_r:user_mail_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(09/09/2019 06:44:44.467:377) : avc:  denied  { write } for  pid=9115 comm=postalias name=aliases.db dev="vda1" ino=72 scontext=sysadm_u:sysadm_r:user_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_aliases_t:s0 tclass=file permissive=0 
----

Following SELinux denial appeared in permissive mode:
----
type=PROCTITLE msg=audit(09/09/2019 06:47:16.404:380) : proctitle=postalias hash /etc/aliases 
type=SYSCALL msg=audit(09/09/2019 06:47:16.404:380) : arch=x86_64 syscall=open success=yes exit=5 a0=0x5597f49094a0 a1=O_RDWR a2=0x1a4 a3=0x3 items=0 ppid=9103 pid=9120 auid=sysadm-user uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=4 comm=postalias exe=/usr/sbin/postalias subj=sysadm_u:sysadm_r:user_mail_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(09/09/2019 06:47:16.404:380) : avc:  denied  { write } for  pid=9120 comm=postalias name=aliases.db dev="vda1" ino=72 scontext=sysadm_u:sysadm_r:user_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_aliases_t:s0 tclass=file permissive=1 
----

Comment 4 Milos Malik 2019-09-09 10:56:02 UTC

$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023
$ su
Password: 
# id
uid=0(root) gid=0(root) groups=0(root) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023
# newaliases
postalias: fatal: open /etc/aliases.db: Permission denied
#

Following SELinux denial appeared in enforcing mode:
----
type=PROCTITLE msg=audit(09/09/2019 06:52:46.945:445) : proctitle=postalias hash /etc/aliases 
type=SYSCALL msg=audit(09/09/2019 06:52:46.945:445) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x555c1e8b34a0 a1=O_RDWR a2=0x1a4 a3=0x3 items=0 ppid=9186 pid=9199 auid=staff-user uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=5 comm=postalias exe=/usr/sbin/postalias subj=staff_u:staff_r:user_mail_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(09/09/2019 06:52:46.945:445) : avc:  denied  { write } for  pid=9199 comm=postalias name=aliases.db dev="vda1" ino=72 scontext=staff_u:staff_r:user_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_aliases_t:s0 tclass=file permissive=0 
----

Following SELinux denial appeared in permissive mode:
----
type=PROCTITLE msg=audit(09/09/2019 06:53:17.805:448) : proctitle=postalias hash /etc/aliases 
type=SYSCALL msg=audit(09/09/2019 06:53:17.805:448) : arch=x86_64 syscall=open success=yes exit=5 a0=0x555642ac44a0 a1=O_RDWR a2=0x1a4 a3=0x3 items=0 ppid=9186 pid=9202 auid=staff-user uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=5 comm=postalias exe=/usr/sbin/postalias subj=staff_u:staff_r:user_mail_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(09/09/2019 06:53:17.805:448) : avc:  denied  { write } for  pid=9202 comm=postalias name=aliases.db dev="vda1" ino=72 scontext=staff_u:staff_r:user_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_aliases_t:s0 tclass=file permissive=1 
----

Comment 7 Zdenek Pytela 2019-09-12 09:02:08 UTC

This issue was not selected to be included in Red Hat Enterprise Linux 7 because it is seen either as low or moderate impact to a small number of use-cases. The next minor release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available.

We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise, we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.

Note You need to log in before you can comment on or make changes to this bug.