linux-kernel - Re: [PATCH v5 4/4] vduse: Add LSM hook to check Virtio device type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhSkGwzWV8T06LdoGXyvrnP7tiYMPYmbmVxWoQg6wzEDiQ@mail.gmail.com>
Date: Tue, 19 Dec 2023 13:20:31 -0500
From: Paul Moore <paul@...l-moore.com>
To: Stephen Smalley <stephen.smalley.work@...il.com>
Cc: Maxime Coquelin <maxime.coquelin@...hat.com>, mst@...hat.com, jasowang@...hat.com, 
	xuanzhuo@...ux.alibaba.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?

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