From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.org>,
John Johansen <john.johansen@canonical.com>,
Paul Moore <paul@paul-moore.com>,
Kevin Locke <kevin@kevinlocke.name>,
Josh Triplett <josh@joshtriplett.org>,
Mateusz Guzik <mjguzik@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
Kentaro Takeda <takedakn@nttdata.co.jp>
Subject: Re: [6.8-rc1 Regression] Unable to exec apparmor_parser from virt-aa-helper
Date: Sat, 27 Jan 2024 16:04:01 +0900 [thread overview]
Message-ID: <b5a12ecd-468d-4b50-9f8c-17ae2a2560b4@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <CAHk-=wjF=zwZ88vRZe-AvexnmP1OCpKZSp_2aCfTpGeH1vLMkA@mail.gmail.com>
On 2024/01/26 2:17, Linus Torvalds wrote:
> On Thu, 25 Jan 2024 at 06:17, Tetsuo Handa
> <penguin-kernel@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@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".
next prev parent reply other threads:[~2024-01-27 7:05 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 16:19 [6.8-rc1 Regression] Unable to exec apparmor_parser from virt-aa-helper Kevin Locke
2024-01-24 16:35 ` Kees Cook
2024-01-24 16:46 ` Linus Torvalds
2024-01-24 16:54 ` Linus Torvalds
2024-01-24 17:10 ` Linus Torvalds
2024-01-24 17:21 ` Kees Cook
2024-01-24 17:27 ` Linus Torvalds
2024-01-24 18:27 ` Linus Torvalds
2024-01-24 18:29 ` Linus Torvalds
2024-01-24 19:02 ` Kees Cook
2024-01-24 19:41 ` Linus Torvalds
2024-01-25 14:16 ` Tetsuo Handa
2024-01-25 17:17 ` Linus Torvalds
2024-01-27 7:04 ` Tetsuo Handa [this message]
2024-01-27 11:00 ` Tetsuo Handa
2024-01-27 11:23 ` Tetsuo Handa
2024-01-24 18:57 ` Kees Cook
2024-01-27 5:17 ` John Johansen
2024-01-24 17:15 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b5a12ecd-468d-4b50-9f8c-17ae2a2560b4@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=john.johansen@canonical.com \
--cc=josh@joshtriplett.org \
--cc=keescook@chromium.org \
--cc=kevin@kevinlocke.name \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mjguzik@gmail.com \
--cc=paul@paul-moore.com \
--cc=takedakn@nttdata.co.jp \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).