[RFC PATCH] fs: Add vfs_masks_device_ioctl*() helpers

[Paul Moore]

On Thu, Mar 7, 2024 at 6:09 PM Dave Chinner <david at fromorbit.com> 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 at google.com> wrote:
> > > On Thu, Mar 07, 2024 at 01:21:48PM +0100, Arnd Bergmann wrote:
> > > > On Thu, Mar 7, 2024, at 13:15, Christian Brauner wrote:
> > > > > On Wed, Mar 06, 2024 at 04:18:53PM +0100, Arnd Bergmann wrote:
> > > > >> On Wed, Mar 6, 2024, at 14:47, Mickaël Salaün wrote:
> > > > >> >
> > > > >> > Arnd, Christian, Paul, are you OK with this new hook proposal?
> > > > >>
> > > > >> I think this sounds better. It would fit more closely into
> > > > >> the overall structure of the ioctl handlers with their multiple
> > > > >> levels, where below vfs_ioctl() calling into f_ops->unlocked_ioctl,
> > > > >> you have the same structure for sockets and blockdev, and
> > > > >> then additional levels below that and some weirdness for
> > > > >> things like tty, scsi or cdrom.
> > > > >
> > > > > So an additional security hook called from tty, scsi, or cdrom?
> > > > > And the original hook is left where it is right now?
> > > >
> > > > For the moment, I think adding another hook in vfs_ioctl()
> > > > and the corresponding compat path would do what Mickaël
> > > > wants. Beyond that, we could consider having hooks in
> > > > socket and block ioctls if needed as they are easy to
> > > > filter out based on inode->i_mode.
> > > >
> > > > The tty/scsi/cdrom hooks would be harder to do, let's assume
> > > > for now that we don't need them.
> > >
> > > Thank you all for the help!
> > >
> > > Yes, tty/scsi/cdrom are just examples.  We do not need special features for
> > > these for Landlock right now.
> > >
> > > What I would do is to invoke the new LSM hook in the following two places in
> > > fs/ioctl.c:
> > >
> > > 1) at the top of vfs_ioctl()
> > > 2) at the top of ioctl_compat()
> > >
> > > (Both of these functions are just invoking the f_op->unlocked_ioctl() and
> > > f_op->compat_ioctl() operations with a safeguard for that being a NULL pointer.)
> > >
> > > The intent is that the new hook gets called everytime before an ioctl is sent to
> > > these IOCTL operations in f_op, so that the LSM can distinguish cleanly between
> > > the "safe" IOCTLs that are implemented fully within fs/ioctl.c and the
> > > "potentially unsafe" IOCTLs which are implemented by these hooks (as it is
> > > unrealistic for us to holistically reason about the safety of all possible
> > > implementations).
> > >
> > > The alternative approach where we try to do the same based on the existing LSM
> > > IOCTL hook resulted in the patch further up in this mail thread - it involves
> > > maintaining a list of "safe" IOCTL commands, and it is difficult to guarantee
> > > that these lists of IOCTL commands stay in sync.
> >
> > 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's the point I was trying to make.  I'm not sure exactly what
Günther meant either (I was simply copying his idea of a "safe" ioctl,
complete with all of the associations around the double quotes), which
helps underscore the idea that different groups are likely to have
different ideas of what ioctls they want to allow based on their
security model, environment, etc.

> > At this point in time, I think I'd rather see LSMs that care about
> > ioctls maintaining their own list of "safe" ioctls and after a while
> > if it looks like everyone is in agreement (VFS folks, individual LSMs,
> > etc.) we can look into either an ioctl classifier or multiple LSM
> > ioctl hooks focused on different categories of ioctls.
>
> From the perspective of a VFS and subsystem developer, I really have
> no clue what would make a "safe" ioctl from a LSM perspective ...

We also need to keep in mind that we have multiple LSM implementations
and we need to support different ideas around how to control access to
ioctls, including which ioctls are "safe" for multiple definitions of
the word.

> ... and I
> very much doubt an LSM developer has any clue whether deep, dark
> subsystem ioctls are "safe" to allow, or even what would stop
> working if they decided something was not "safe".

... or for those LSMs with configurable security policies, which
ioctls are allowed by the LSM's policy developer to fit their
particular needs.

> This just seems like a complex recipe for creating unusable and/or
> impossible to configure/secure systems to me.

FWIW, Android has been using the existing LSM ioctl controls for
several years now to help increase the security of Android devices.

https://security.googleblog.com/2016/07/protecting-android-with-more-linux.html
https://kernsec.org/files/lss2015/vanderstoep.pdf

-- 
paul-moore.com