On Fri, Mar 8, 2024, at 00:09, Dave Chinner wrote:
> On Thu, Mar 07, 2024 at 03:40:44PM -0500, Paul Moore wrote:
>> On Thu, Mar 7, 2024 at 7:57 AM Günther Noack <gnoack@xxxxxxxxxx> wrote:
>> I need some more convincing as to why we need to introduce these new
>> hooks, or even the vfs_masked_device_ioctl() classifier as originally
>> proposed at the top of this thread. I believe I understand why
>> Landlock wants this, but I worry that we all might have different
>> definitions of a "safe" ioctl list, and encoding a definition into the
>> LSM hooks seems like a bad idea to me.
>
> I have no idea what a "safe" ioctl means here. Subsystems already
> restrict ioctls that can do damage if misused to CAP_SYS_ADMIN, so
> "safe" clearly means something different here.
That was my problem with the first version as well, but I think
drawing the line between "implemented in fs/ioctl.c" and
"implemented in a random device driver fops->unlock_ioctl()"
seems like a more helpful definition.
This won't just protect from calling into drivers that are lacking
a CAP_SYS_ADMIN check, but also from those that end up being
harmful regardless of the ioctl command code passed into them
because of stupid driver bugs.
Arnd
