On 2024/01/26 2:17, Linus Torvalds wrote: > On Thu, 25 Jan 2024 at 06:17, Tetsuo Handa > <penguin-kernel@xxxxxxxxxxxxxxxxxxx> 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@host ~]$ cat /tmp/foo.sh #!/bin/sh echo hello [user@host ~]$ chmod 755 /tmp/foo.sh [user@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@xxxxxxxxxxxxxxxxxxx and https://lkml.kernel.org/r/201104202120.FEJ57865.MFSOFFHVOOJLQt@xxxxxxxxxxxxxxxxxxx . 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".
