This could be caused by the fact that all the commands you tried *except* the shell built-ins spawn a new process.  Have you verified that the actual shell process running those built-ins is not permitted to access /etc/shadow for reading?

Something like this could help:

# read </etc/shadow

I further checked (using gdb) that kernel indeed returns -1 to bash,

0x00007f4080ff7980 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:81
81      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Missing separate debuginfos, use: debuginfo-install ncurses-libs-5.9-13.20130511.el7.x86_64
(gdb) call access("/etc/shadow", 4)
$1 = -1

where 4 is

/usr/include/unistd.h:#define   R_OK    4               /* Test for read permission.  */

just in case there's something weird with execve(2) regarding contexts/transitions and the earlier "exec ./access" wouldn't spot it.

So this indeed seems like a bash issue.

(In reply to Kamil Dudka from comment #1)
> This could be caused by the fact that all the commands you tried *except*
> the shell built-ins spawn a new process.  Have you verified that the actual
> shell process running those built-ins is not permitted to access /etc/shadow
> for reading?
> 
> Something like this could help:
> 
> # read </etc/shadow

Please see the comment #0 thoroughly, I go into extra detail regarding that.

# test -r /etc/shadow; echo $?
0

# read </etc/shadow
bash: /etc/shadow: Permission denied

Thanks,
Jiri

(In reply to Jiri Jaburek from comment #4)
> Please see the comment #0 thoroughly, I go into extra detail regarding that.

I did.  There was no command attempting to read the command in the *same* process in which you run the built-ins in question.

> # test -r /etc/shadow; echo $?
> 0
> 
> # read </etc/shadow
> bash: /etc/shadow: Permission denied

OK.  Thanks for confirmation!

(In reply to Kamil Dudka from comment #5)
> There was no command attempting to read the command in the same process...

Sorry, I meant read the *file* in the same process...

bash uses faccessat() instead of access() to check permissions which might cause some differences :

faccessat (AT_FDCWD, path, mode, AT_EACCESS)

I have tried reproducing this bug on a RHEL 7.2 server minimal install by following below steps :

1. Install RHEL 7.2 server minimal.

2. Enable MLS by following steps from https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/mls.html

3. I was not able to login to tty after enabling MLS in enforcing mode, so I booted with 'enforce=0' parameter, logged in as root and did 'setenforce 1' to enable MLS.

However this issue was not reproducible.

A reproducer machine has been provided. I'm taking this bug on the QE side, we'll verify the solution during MLS testing.

faccessat() function seems to behave differently with AT_EACCESS flag :

(gdb) p faccessat (-100, "/etc/shadow", 4, 512) 
$1 = 0

where AT_EACCESS=512. 

Otherwise it works correctly.
(gdb) p access("/etc/shadow", 4)
$3 = -1
(gdb) p faccessat (-100, "/etc/shadow", 4, 0) 
$4 = -1


I am still checking how effective user id of the process is different from it's real user id.

The root cause of this issue is value of '__libc_enable_secure' variable. This variable is being checked in faccessat() function in glibc-2.17-c758a686/sysdeps/unix/sysv/linux/faccessat.c :

On ssh session it is set to 0 :

(gdb) p __libc_enable_secure
$1 = 0

so this condition will be true :

     45   if ((flag == 0 || ((flag & ~AT_EACCESS) == 0 && ! __libc_enable_secure))
     46 # ifndef __ASSUME_ATFCTS
     47       && __have_atfcts >= 0
     48 # endif
     49       )
     50     {
     51       int result = INLINE_SYSCALL (faccessat, 3, fd, file, mode);
     52 # ifndef __ASSUME_ATFCTS
     53       if (result == -1 && errno == ENOSYS)
     54 	__have_atfcts = -1;
     55       else
     56 # endif
     57 	return result;
     58     }
     59 #endif


and actual 'faccessat()' system call is made to verify file permissions.

However on tty it is set to 1 :

(gdb) p __libc_enable_secure
$1 = 1

so this condition will be true :

    131   if (uid == 0 && ((mode & X_OK) == 0
    132 		   || (stats.st_mode & (S_IXUSR | S_IXGRP | S_IXOTH))))
    133     return 0;
    134 

and since root is trying to acccess the file, permissions will be granted without further checking SELinux permissions.

bash has AT_SECURE flag enabled when it is started via tty :

(gdb) p getauxval(23)
$1 = 1

This would enable '__libc_enable_secure' variable in glibc-2.17-c758a686/elf/dl-sysdep.c :

    147       case AT_SECURE:
    148 #ifndef HAVE_AUX_SECURE
    149 	seen = -1;
    150 #endif
    151 	INTUSE(__libc_enable_secure) = av->a_un.a_val;
    152 	break;

It seems MLS enables AT_SECURE flag while starting bash via tty.

We need proper kernel interfaces to fix this.  There is no other way.  I filed bug 1333764 to cover the kernel side.

We are tracking this upstream. We need kernel support for this first, anyway. If upstream support becomes available, we can consider backporting the change (the glibc part will be easy enough).

The upstream fix is here:

commit 3d3ab573a5f3071992cbc4f57d50d1d29d55bde2
Author: Florian Weimer <fweimer>
Date:   Fri Aug 7 22:06:59 2020 +0200

    Linux: Use faccessat2 to implement faccessat (bug 18683)
    
    This provides correct AT_EACCESS handling and also takes
    Linux security modules into account.
    
    Reviewed-by: Adhemerval Zanella <adhemerval.zanella>

This can work with a RHEL8/UBI8 container running on RHEL9 host (Kernel 5.14).

Reopening for consideration in RHEL 8.

Our experience with fixing this in Fedora and Red Hat Enterprise Linux 9 shows that such a change in the system call profile of glibc can be very disruptive. The faccessat function is used in key places in bash and systemd, so the new system call would be used immediately by containers. Most of the system call filtering issues should have been fixed by now. On the other hand, it is relatively late in the Red Hat Enterprise Linux 8 life-cycle, and this change is too disruptive at this point.