[External] Re: security_file_free contract/expectations

[Paul Moore]

On Thu, Jan 25, 2024 at 12:19 PM Ben Smith <ben.smith at crowdstrike.com> wrote:
> On 1/25/24, 7:19 AM, "Tetsuo Handa" <penguin-kernel at I-love.SAKURA.ne.jp <mailto:penguin-kernel at I-love.SAKURA.ne.jp>> wrote:
> > I guess the out-of-tree filesystems are used by CrowdStrike products and
> > therefore the source code etc. cannot be shared. (It took me 2 years to prove
> > that an out-of-tree filesystem used by TrendMicro products was the culprit.)
> > But are you sure that the location that triggered panic is at reading current->fs ?
>
> Yes, unfortunately the source can't be shared. From the stack I can see that the NULL dereference does
> not happen in crowdstrike code, it happens in mvfs (Clearcase MVFS), which I do
> not have sources for. From crash analysis I'm pretty confident that mvfs accessing
> current->fs led to the crash.
>
> > security_file_free() is not meant for reading files. But if the location were
> > really at reading current->fs, whether an LSM shouldn't try to read a file from
> > security_file_free() is a bogus question.
>
> The underlying filesystem, as part of reading files appears to use current->fs
> (I assume it's looking up something about the calling process since it's a
> versioned file system). So, my question was who is doing something unusual here?
> Is it the LSM in opening a file in the context of a partially freed task or the
> filesystem in blindly using a field of the task struct without checking whether it's NULL.
>
> > security_file_release() proposed by Roberto Sassu would be OK. But I guess that
> > the kernel version you want to load the out-of-tree filesystems is not the latest...
>
> > Without more details, we can't give you appropriate suggestions.
>
> My feeling was that reading a file from security_file_free() was not a good idea
> but I wanted to clarify expectations and make sure I wasn't making an incorrect assumption.
> Casey's reply cleared that up for me, so I've got what I need and have a path forward.

I also want to make it clear that there are no guarantees that the LSM
hooks you're concerned about won't change tomorrow; the kernel's
stable ABI guarantee does not extend to the LSM hooks.  If you, or
your company, make the decision to support out-of-tree kernel code
that relies on the LSM hooks, the expectation is that you will be
shouldering the support burden yourself.

-- 
paul-moore.com