Question about security_file_open contract

[Casey Schaufler]

On 11/18/2020 12:44 PM, Martin Kelly wrote:
> Hi,
>
> I'm debugging a thorny problem and want to verify my understanding about the
> expected contract between LSM and kernel drivers. Specifically, I'm hitting
> an issue in which the following occurs:
>
> - A process exits, calling task_exit().
> - exit_fs() is called, setting current->fs = NULL.
> - Next, exit_task_work() is called, which calls fput().
> - In response to the fput(), the filesystem opens a file to update some
> metadata, calling dentry_open().

Which process do you expect the file to be opened for? As you
point out, current is being torn down. What is your kernel driver
doing that led you to think this was a good idea?


> - dentry_open() calls security_file_open(), calling into the LSM. The LSM
> crashes because it assumes it's called from process context and thus
> current->fs is not NULL.

Right. Without a valid process context it's impossible to make
access control decisions.

>
> I'm trying to figure out exactly what the contract is here. Is it safe for
> an LSM to assume current->fs should be non-NULL when security_file_open is
> called?  More generally, is it safe for an LSM to assume that
> security_file_open will always be called from process context? In other
> words, is the LSM at fault here or the driver?

The driver. If you want to open files directly from the driver,
as opposed to from a process, you need a valid kernel context.

> Thanks,
> Martin