RE: selinux strange behaviour

[GRAVIER Michel]

I understand the problem. Thanks for your answer.

________________________________
De : Stephen Smalley <sds(a)tycho.nsa.gov&gt;
Envoyé : vendredi 15 novembre 2019 16:41
À : GRAVIER Michel <michel.gravier(a)external.mythalesgroup.io>;
selinux(a)lists.fedoraproject.org <selinux(a)lists.fedoraproject.org&gt;
Objet : 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@...

This message contains confidential information and is intended only for the individual(s)
addressed in the message. If you are not the named addressee, you should not disseminate,
distribute, or copy this e-mail. If you are not the intended recipient, you are notified
that disclosing, distributing, or copying this e-mail is strictly prohibited.