[6.8-rc1 Regression] Unable to exec apparmor_parser from virt-aa-helper

[Tetsuo Handa]

On 2024/01/26 2:17, Linus Torvalds wrote:
> On Thu, 25 Jan 2024 at 06:17, Tetsuo Handa
> <penguin-kernel at i-love.sakura.ne.jp> wrote:
>>
>> On 2024/01/25 3:27, Linus Torvalds wrote:
>>> The whole cred use of current->in_execve in tomoyo should
>>> *also* be fixed, but I didn't even try to follow what it actually
>>> wanted.
>>
>> Due to TOMOYO's unique domain transition (transits to new domain before
>> execve() succeeds and returns to old domain if execve() failed), TOMOYO
>> depends on a tricky ordering shown below.
> 
> Ok, that doesn't really clarify anything for me.
> 
> I'm less interested in what the call paths are, and more like "_Why_
> is all this needed for tomoyo?"
> 
> Why doesn't tomoyo just install the new cred at "commit_creds()" time?
> 
> (The security hooks that surround that  are
> "->bprm_committing_creds()" and "->bprm_committed_creds()")

DAC checks permission for any files accessed by a new program passed to execve()
until the point of no return of execve() using the credentials of current program.
But TOMOYO checks permission for any files accessed by a new program passed to execve()
using a domain for that new program than a domain for current program.

This is because TOMOYO considers that if a new program passed to execve() requires some
file, permissions for accessing that file should be checked using the security context
for that new program.

Let's consider executing a shell script named /tmp/foo.sh from /bin/bash .

  [user at host ~]$ cat /tmp/foo.sh
  #!/bin/sh
  echo hello
  [user at host ~]$ chmod 755 /tmp/foo.sh
  [user at host ~]$ exec /tmp/foo.sh

DAC checks permissions for /tmp/foo.sh and /bin/sh using the credentials of /bin/bash
process, and checks permissions for shared libraries needed by /bin/sh using the new
credentials of /tmp/foo.sh process.

TOMOYO checks permissions for /tmp/foo.sh using the domain for /bin/bash process, and
checks permissions for /bin/sh and permissions for shared libraries needed by /bin/sh
using the domain for /tmp/foo.sh process. TOMOYO treats "/tmp/foo.sh needs to load /bin/sh"
and "/tmp/foo.sh needs to load shared libraries needed by /bin/sh" in the same manner, by
checking "open for read" permission.

Since the COW cred mechanism introduced in Linux 2.6.29 cannot support such model,
TOMOYO uses "struct task_struct"->security and does not use "struct cred"->security.

> 
> IOW, the whole "save things across two *independent* execve() calls"
> seems crazy.
> 
> Very strange and confusing.
> 
>                     Linus

Since curity_bprm_free() callback was removed in Linux 2.6.29 because COW cred mechanism
does not need it, currently I have to use such a crazy hack.

Revival of security_task_alloc()/security_task_free()/security_bprm_free() was proposed
in 2011 at https://lkml.kernel.org/r/201104202119.FAI21341.HtOJFSOVLFMOFQ@I-love.SAKURA.ne.jp
and https://lkml.kernel.org/r/201104202120.FEJ57865.MFSOFFHVOOJLQt@I-love.SAKURA.ne.jp .

security_task_alloc()/security_task_free() has been revived, but security_bprm_free() is not
revived yet.

If we can accept revival of security_bprm_free(), we can "get rid of current->in_execve flag"
and "stop saving things across two *independent* execve() calls".