[PATCH v12 1/9] security: Introduce ENOFILEOPS return value for IOCTL hooks

[Arnd Bergmann]

On Tue, Mar 26, 2024, at 11:10, Mickaël Salaün wrote:
> On Tue, Mar 26, 2024 at 10:33:23AM +0100, Arnd Bergmann wrote:
>> On Tue, Mar 26, 2024, at 09:32, Mickaël Salaün wrote:
>> >
>> > This is indeed a simpler solution but unfortunately this doesn't fit
>> > well with the requirements for an access control, especially when we
>> > need to log denied accesses.  Indeed, with this approach, the LSM (or
>> > any other security mechanism) that returns ENOFILEOPS cannot know for
>> > sure if the related request will allowed or not, and then it cannot
>> > create reliable logs (unlike with EACCES or EPERM).
>> 
>> Where does the requirement come from specifically, i.e.
>> who is the consumer of that log?
>
> The audit framework may be used by LSMs to log denials.
>
>> 
>> Even if the log doesn't tell you directly whether the ioctl
>> was ultimately denied, I would think logging the ENOFILEOPS
>> along with the command number is enough to reconstruct what
>> actually happened from reading the log later.
>
> We could indeed log ENOFILEOPS but that could include a lot of allowed
> requests and we usually only want unlegitimate access requests to be
> logged.  Recording all ENOFILEOPS would mean 1/ that logs would be
> flooded by legitimate requests and 2/ that user space log parsers would
> need to deduce if a request was allowed or not, which require to know
> the list of IOCTL commands implemented by fs/ioctl.c, which would defeat
> the goal of this specific patch.

Right, makes sense. Unfortunately that means I don't see any
option that I think is actually better than what we have today,
but that forces the use of a custom whitelist or extra logic in
landlock.

I didn't really mind having an extra hook for the callbacks
in addition to the top-level one, but that was already nacked.

      Arnd