linux-kernel - Re: [6.8-rc1 Regression] Unable to exec apparmor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b5a12ecd-468d-4b50-9f8c-17ae2a2560b4@I-love.SAKURA.ne.jp>
Date: Sat, 27 Jan 2024 16:04:01 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Kees Cook <keescook@...omium.org>,
        John Johansen <john.johansen@...onical.com>,
        Paul Moore
 <paul@...l-moore.com>, Kevin Locke <kevin@...inlocke.name>,
        Josh Triplett <josh@...htriplett.org>,
        Mateusz Guzik <mjguzik@...il.com>, Al Viro <viro@...iv.linux.org.uk>,
        linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org,
        Kentaro Takeda <takedakn@...data.co.jp>
Subject: Re: [6.8-rc1 Regression] Unable to exec apparmor_parser from
 virt-aa-helper

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