Bug 1688887

Updated proposed module:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
module sudo-bz1688887 1.0;

require {
    type security_t;
    attribute sudodomain;
    type lastlog_t;
    class passwd passwd;
    class netlink_selinux_socket { bind create };
    class file { open read write };
    class security compute_av;
}

allow sudodomain lastlog_t:file { open read write };
allow sudodomain security_t:security compute_av;
allow sudodomain self:netlink_selinux_socket { bind create };
allow sudodomain self:passwd passwd;
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This issue was not selected to be included in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small number of use-cases. The next 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.

Please reconsider this bug. I've attached a new case that's affected by this.

DISA STIG requires that all users be confined. BZ#1727379 indicates problems
with accessing sysadm_u accounts via graphical login and/or ssh.

To add to this bug, staff_u users cannot elevate priviliges successfully with 
su or sudo. sudo comes deceptively close, but a user elevated with it cannot
access files with admin_home_t context, such as root rc files:

[testuser@dhcp-49-19 ~]$ sudo -i
-bash: /root/.bash_profile: Permission denied
-bash-4.2# ls -laZ .bash_profile
ls: cannot access .bash_profile: Permission denied
-bash-4.2# ls -laZ | head
ls: cannot access .bash_logout: Permission denied
ls: cannot access .bash_profile: Permission denied
ls: cannot access .bashrc: Permission denied
ls: cannot access .cshrc: Permission denied
ls: cannot access .tcshrc: Permission denied
ls: cannot access anaconda-ks.cfg: Permission denied
ls: cannot access .bash_history: Permission denied
ls: cannot access xorg-x11-server-Xdmx-1.20.1-5.3.el7_6.x86_64.rpm: Permission denied
ls: cannot access .lesshst: Permission denied
dr-xr-x---. root root system_u:object_r:admin_home_t:s0 .
dr-xr-xr-x. root root system_u:object_r:root_t:s0      ..
?---------  ?    ?                                     anaconda-ks.cfg
?---------  ?    ?                                     .bash_history
?---------  ?    ?                                     .bash_logout
?---------  ?    ?                                     .bash_profile
?---------  ?    ?                                     .bashrc
drwx------. root root unconfined_u:object_r:cache_home_t:s0 .cache
drwxr-xr-x. root root unconfined_u:object_r:config_home_t:s0 .config
?---------  ?    ?                                     .cshrc

We need this to work for our existing customers, who use Red Hat because of
our compliance advantages, and RHEL 8 won't be an option for them for quite
some time in some cases.

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.

For possible workarounds, please refer to the attached knowledgebase article.

Please disregard the previous comment and resolution, the requested permissions seem to have already been present in the current development package version as a result of other implemented changes.

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-2020:1007

This is not resolved. I have the same issue running RHEL 7.9.

(In reply to john.shaw from comment #25)
> This is not resolved. I have the same issue running RHEL 7.9.

Yes. We are still having this issue as well. RHEL 7.9