On 2024/01/26 2:17, Linus Torvalds wrote:

On Thu, 25 Jan 2024 at 06:17, Tetsuo Handa
[off-list ref] wrote:

quoted

On 2024/01/25 3:27, Linus Torvalds wrote:

quoted

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@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".