On Tue, Mar 26, 2024, at 09:32, Mickaël Salaün wrote:
> On Mon, Mar 25, 2024 at 04:19:25PM +0100, Arnd Bergmann wrote:
>> On Mon, Mar 25, 2024, at 14:39, Günther Noack wrote:
>> > If security_file_ioctl or security_file_ioctl_compat return
>> > ENOFILEOPS, the IOCTL logic in fs/ioctl.c will permit the given IOCTL
>> > command, but only as long as the IOCTL command is implemented directly
>> > in fs/ioctl.c and does not use the f_ops->unhandled_ioctl or
>> > f_ops->compat_ioctl operations, which are defined by the given file.
>> >
>> > The possible return values for security_file_ioctl and
>> > security_file_ioctl_compat are now:
>> >
>> > * 0 - to permit the IOCTL
>> > * ENOFILEOPS - to permit the IOCTL, but forbid it if it needs to fall
>> > back to the file implementation.
>> > * any other error - to forbid the IOCTL and return that error
>> >
>> > This is an alternative to the previously discussed approaches [1] and [2],
>> > and implements the proposal from [3].
>>
>> Thanks for trying it out, I think this is a good solution
>> and I like how the code turned out.
>
> 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?
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.
Arnd
