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

[Maxime Coquelin <maxime.coquelin@redhat.com>]

On 12/18/23 18:33, Stephen Smalley wrote:
> On Mon, Dec 18, 2023 at 12:21 PM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
>>
>> On Tue, Dec 12, 2023 at 8:17 AM Maxime Coquelin
>> <maxime.coquelin@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?
> 
> (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.

Got it, that seems indeed more appropriate than using persmission bits
for the device type.

> - 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.

Ok.

> 

Thanks for the insights, I'll try and see if I can follow your
recommendations in a dedicated series.

Maxime