Re: selinux strange behaviour

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx/
_______________________________________________
selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/selinux@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux