Messages in this thread | | | Date | Tue, 24 Oct 2023 11:49:01 +0200 | Subject | Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type | From | Maxime Coquelin <> |
| |
On 10/23/23 17:13, Casey Schaufler wrote: > On 10/23/2023 12:28 AM, Maxime Coquelin wrote: >> >> >> On 10/21/23 00:20, Casey Schaufler wrote: >>> On 10/20/2023 8:58 AM, Maxime Coquelin wrote: >>>> This patch introduces LSM hooks for devices creation, >>>> destruction and opening operations, checking the >>>> application is allowed to perform these operations for >>>> the Virtio device type. >>> >>> Why do you think that there needs to be a special LSM check for virtio >>> devices? What can't existing device attributes be used? >> >> Michael asked for a way for SELinux to allow/prevent the creation of >> some types of devices [0]. >> >> A device is created using ioctl() on VDUSE control chardev. Its type is >> specified via a field in the structure passed in argument. >> >> I didn't see other way than adding dedicated LSM hooks to achieve this, >> but it is possible that their is a better way to do it? > > At the very least the hook should be made more general, and I'd have to > see a proposal before commenting on that. security_dev_destroy(dev) might > be a better approach. If there's reason to control destruction of vduse > devices it's reasonable to assume that there are other devices with the > same or similar properties.
VDUSE is different from other devices as the device is actually implemented by the user-space application, so this is very specific in my opinion.
> > Since SELinux is your target use case, can you explain why you can't > create SELinux policy to enforce the restrictions you're after? I believe > (but can be proven wrong, of course) that SELinux has mechanism for dealing > with controls on ioctls. >
I am not aware of such mechanism to deal with ioctl(), if you have a pointer that would be welcome.
Thanks, Maxime
> >> >> Thanks, >> Maxime >> >> [0]: >> https://lore.kernel.org/all/20230829130430-mutt-send-email-mst@kernel.org/ >> >
| |