[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEjxPJ77cdHUvxWqLzmYwjLqFiSJH4kwByx7vAvR7dLfqcLy0g@mail.gmail.com>
Date: Mon, 18 Dec 2023 12:33:33 -0500
From: Stephen Smalley <stephen.smalley.work@...il.com>
To: Maxime Coquelin <maxime.coquelin@...hat.com>, Ondrej Mosnacek <omosnace@...hat.com>
Cc: mst@...hat.com, jasowang@...hat.com, xuanzhuo@...ux.alibaba.com,
paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com,
eparis@...isplace.org, xieyongji@...edance.com,
virtualization@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, selinux@...r.kernel.org,
david.marchand@...hat.com, lulu@...hat.com, casey@...aufler-ca.com
Subject: Re: [PATCH v5 4/4] vduse: Add LSM hook to check Virtio device type
On Mon, Dec 18, 2023 at 12:21 PM Stephen Smalley
<stephen.smalley.work@...il.com> wrote:
>
> On Tue, Dec 12, 2023 at 8:17 AM Maxime Coquelin
> <maxime.coquelin@...hat.com> wrote:
> >
> > This patch introduces a LSM hook for devices creation,
> > destruction (ioctl()) and opening (open()) operations,
> > checking the application is allowed to perform these
> > operations for the Virtio device type.
>
> Can you explain why the existing LSM hooks and SELinux implementation
> are not sufficient? We already control the ability to open device
> nodes via selinux_inode_permission() and selinux_file_open(), and can
> support fine-grained per-cmd ioctl checking via selinux_file_ioctl().
> And it should already be possible to label these nodes distinctly
> through existing mechanisms (file_contexts if udev-created/labeled,
> genfs_contexts if kernel-created). What exactly can't you do today
> that this hook enables?
(added Ondrej to the distribution; IMHO we should swap him into
MAINTAINERS in place of Eric Paris since Eric has long-since moved on
from SELinux and Ondrej serves in that capacity these days)
Other items to consider:
- If vduse devices are created using anonymous inodes, then SELinux
grew a general facility for labeling and controlling the creation of
those via selinux_inode_init_security_anon().
- You can encode information about the device into its SELinux type
that then allows you to distinguish things like net vs block based on
the device's SELinux security context rather than encoding that in the
permission bits.
- If you truly need new LSM hooks (which you need to prove first),
then you should pass some usable information about the object in
question to allow SELinux to find a security context for it. Like an
inode associated with the device, for example.
Powered by blists - more mailing lists