Re: selinux strange behaviour
On 11/15/19 9:15 AM, Michel Gravier wrote:
Dear all
I try to forbid execution of script on user home by standard user. Here what I have done
:
Change the boolean user_exec_content to off :
# setsebool user_exec_content off
So if i read policies any process with the user_t domain should not be able to exec a
file with user_home_t type ?
So i create a user "toto" with the context :
$ id -Z
user_u:user_r:user_t:s0
I create a bash script "test.sh" with 2 lines :
#!/bin/bash
ps -fZ
$ ll -Z
total 3
-rwxr-xr-x. 1 toto toto user_u:object_r:user_home_t:s0 19 15 nov. 08:00 test.sh
When i try to execute de script :
$ ./test.sh
-bash: ./test.sh: Permission denied
That's what I wanted. And it's SELinux which do the work :
# tail -3 /var/log/audit/audit.log
type=AVC msg=audit(1573824552.173:265): avc: denied { execute } for pid=15138
comm="bash" name="test.sh" dev="dm-0" ino=341980
scontext=user_u:user_r:user_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file
permissive=0
type=SYSCALL msg=audit(1573824552.173:265): arch=c000003e syscall=59 success=no exit=-13
a0=55ed16979130 a1=55ed169ad730 a2=55ed169856c0 a3=8 items=0 ppid=14703 pid=15138
auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000
tty=pts1 ses=9 comm="bash" exe="/usr/bin/bash"
subj=user_u:user_r:user_t:s0 key=(null)ARCH=x86_64 SYSCALL=execve AUID="toto"
UID="toto" GID="toto" EUID="toto" SUID="toto"
FSUID="toto" EGID="toto" SGID="toto" FSGID="toto"
type=PROCTITLE msg=audit(1573824552.173:265): proctitle="-bash"
But if I do this :
$ bash test.sh
LABEL UID PID PPID C STIME TTY TIME CMD
user_u:user_r:user_t:s0 toto 14703 14702 0 08:00 pts/1 00:00:00 -bash
user_u:user_r:user_t:s0 toto 15147 14703 0 08:31 pts/1 00:00:00 bash test.sh
user_u:user_r:user_t:s0 toto 15148 15147 0 08:31 pts/1 00:00:00 ps -fZ
I'm quite surprise of the result !? Why the second bash (pid 15147) is authorized to
execute "test.sh" ?
Thanks for your attention.
Because scripts are interpreted/read, not executed. Direct invocation
(./test.sh) performs an execve() and the kernel can apply an execute
check at that time before starting the interpreter and passing it the
script file. Running it explicitly via the interpreter (bash test.sh)
just open()'s the file O_RDONLY, reads its content, and interprets it.
Hence, you'd have to deny read permission to user_home_t, which wouldn't
work very well. There are patches floating about to introduce an
O_MAYEXEC flag to open() for use by interpreters to signal to the kernel
that they intend to "execute" content from the file, which could then
trigger an execute check here as well.
https://lore.kernel.org/linux-security-module/20190906152455.22757-1-mic@...