[PATCH v5 4/4] vduse: Add LSM hook to check Virtio device type
Paul Moore
paul at paul-moore.com
Tue Dec 19 18:20:31 UTC 2023
On Mon, Dec 18, 2023 at 12:21 PM Stephen Smalley
<stephen.smalley.work at gmail.com> wrote:
> On Tue, Dec 12, 2023 at 8:17 AM Maxime Coquelin
> <maxime.coquelin at redhat.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?
I asked something similar back in the v4 patchset to see if there was
some special labeling concerns that required the use of a dedicated
hook and from what I can see there are none.
> 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().
For the vduse folks, the associated LSM API function is
security_inode_init_security_anon(); please don't call into SELinux
directly.
> - 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.
I agree with Stephen and I still remain skeptical that these hooks are
needed. Until I see a compelling case as to why the existing LSM
hooks are not sufficient I can't ACK these hooks.
--
paul-moore.com
More information about the Linux-security-module-archive
mailing list