Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
On Fri, Nov 03, 2023 at 08:55:19AM +0100, Maxime Coquelin wrote: > > > On 11/2/23 19:59, Michael S. Tsirkin wrote: > > On Thu, Nov 02, 2023 at 06:56:59PM +0100, Maxime Coquelin wrote: > > > > > > > > > On 10/24/23 17:30, Casey Schaufler wrote: > > > > On 10/24/2023 2:49 AM, Maxime Coquelin wrote: > > > > > > > > > > > > > > > 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. > > > > > > > > This is hardly unique. If you're implementing the device > > > > in user-space you may well be able to implement the desired > > > > controls there. > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > security/selinux/hooks.c > > > > > > We might be able to extend selinux_file_ioctl(), but that will only > > > covers the ioctl for the control file, this patch also adds hook for the > > > device file opening that would need dedicated hook as the device type > > > information is stored in the device's private data. > > > > > > Michael, before going further, I would be interested in your feedback. > > > Was this patch what you had in mind when requesting for a way to > > > allow/deny devices types for a given application? > > > > > > Regards, > > > Maxime > > > > > > Yes, this is more or less what I had in mind. > > Great. > > Do you think we need to cover both ioctl() on the control file and > open() on the device file, or only ioctl() is enough? > > If the former, we will need VDUSE-specific hooks. I may be able to > improve my patch to have a single hook instead of 3 by passing the type > of operation as an extra argument (create/destroy/open). > > If the latter, we may be able to extend the generic ioctl hook. > > Personally, I think it would make sense to also ensure a given > application can only open existing VDUSE devices it supports. For > example, openvswitch should only be allowed to open networking VDUSE > devices. > > Thanks, > Maxime I agree here. I think an open hook is important. Make sure to document the need in the cover letter and commit log. > > > > > > > > > > > > > > > > Thanks, > > > > > Maxime > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Maxime > > > > > > > > > > > > > > [0]: > > > > > > > https://lore.kernel.org/all/20230829130430-mutt-send-email-...@kernel.org/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
On 11/2/23 19:59, Michael S. Tsirkin wrote: On Thu, Nov 02, 2023 at 06:56:59PM +0100, Maxime Coquelin wrote: On 10/24/23 17:30, Casey Schaufler wrote: On 10/24/2023 2:49 AM, Maxime Coquelin wrote: 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. This is hardly unique. If you're implementing the device in user-space you may well be able to implement the desired controls there. 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. security/selinux/hooks.c We might be able to extend selinux_file_ioctl(), but that will only covers the ioctl for the control file, this patch also adds hook for the device file opening that would need dedicated hook as the device type information is stored in the device's private data. Michael, before going further, I would be interested in your feedback. Was this patch what you had in mind when requesting for a way to allow/deny devices types for a given application? Regards, Maxime Yes, this is more or less what I had in mind. Great. Do you think we need to cover both ioctl() on the control file and open() on the device file, or only ioctl() is enough? If the former, we will need VDUSE-specific hooks. I may be able to improve my patch to have a single hook instead of 3 by passing the type of operation as an extra argument (create/destroy/open). If the latter, we may be able to extend the generic ioctl hook. Personally, I think it would make sense to also ensure a given application can only open existing VDUSE devices it supports. For example, openvswitch should only be allowed to open networking VDUSE devices. Thanks, Maxime Thanks, Maxime Thanks, Maxime [0]: https://lore.kernel.org/all/20230829130430-mutt-send-email-...@kernel.org/ ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
On Thu, Nov 02, 2023 at 06:56:59PM +0100, Maxime Coquelin wrote: > > > On 10/24/23 17:30, Casey Schaufler wrote: > > On 10/24/2023 2:49 AM, Maxime Coquelin wrote: > > > > > > > > > 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. > > > > This is hardly unique. If you're implementing the device > > in user-space you may well be able to implement the desired > > controls there. > > > > > > > > > > > > > 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. > > > > security/selinux/hooks.c > > We might be able to extend selinux_file_ioctl(), but that will only > covers the ioctl for the control file, this patch also adds hook for the > device file opening that would need dedicated hook as the device type > information is stored in the device's private data. > > Michael, before going further, I would be interested in your feedback. > Was this patch what you had in mind when requesting for a way to > allow/deny devices types for a given application? > > Regards, > Maxime Yes, this is more or less what I had in mind. > > > > > > > > Thanks, > > > Maxime > > > > > > > > > > > > > > > > > Thanks, > > > > > Maxime > > > > > > > > > > [0]: > > > > > https://lore.kernel.org/all/20230829130430-mutt-send-email-...@kernel.org/ > > > > > > > > > > > > > > > > > > > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
On 10/24/23 17:30, Casey Schaufler wrote: On 10/24/2023 2:49 AM, Maxime Coquelin wrote: 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. This is hardly unique. If you're implementing the device in user-space you may well be able to implement the desired controls there. 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. security/selinux/hooks.c We might be able to extend selinux_file_ioctl(), but that will only covers the ioctl for the control file, this patch also adds hook for the device file opening that would need dedicated hook as the device type information is stored in the device's private data. Michael, before going further, I would be interested in your feedback. Was this patch what you had in mind when requesting for a way to allow/deny devices types for a given application? Regards, Maxime Thanks, Maxime Thanks, Maxime [0]: https://lore.kernel.org/all/20230829130430-mutt-send-email-...@kernel.org/ ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
On 10/24/2023 2:49 AM, Maxime Coquelin wrote: > > > 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. This is hardly unique. If you're implementing the device in user-space you may well be able to implement the desired controls there. > >> >> 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. security/selinux/hooks.c > > Thanks, > Maxime > >> >>> >>> Thanks, >>> Maxime >>> >>> [0]: >>> https://lore.kernel.org/all/20230829130430-mutt-send-email-...@kernel.org/ >>> >>> >> > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
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-...@kernel.org/ ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
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. 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. > > Thanks, > Maxime > > [0]: > https://lore.kernel.org/all/20230829130430-mutt-send-email-...@kernel.org/ > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
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? Thanks, Maxime [0]: https://lore.kernel.org/all/20230829130430-mutt-send-email-...@kernel.org/ ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
On Fri, Oct 20, 2023 at 11:58 PM 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. > > Signed-off-by: Maxime Coquelin > --- Hi Maxime: I think we need to document the reason why we need those hooks now. Thanks ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
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?
>
> Signed-off-by: Maxime Coquelin
> ---
> drivers/vdpa/vdpa_user/vduse_dev.c | 12 +++
> include/linux/lsm_hook_defs.h | 4 +++
> include/linux/security.h| 15
> security/security.c | 42 ++
> security/selinux/hooks.c| 55 +
> security/selinux/include/classmap.h | 2 ++
> 6 files changed, 130 insertions(+)
>
> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c
> b/drivers/vdpa/vdpa_user/vduse_dev.c
> index 0243dee9cf0e..ca64eac11ddb 100644
> --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> @@ -8,6 +8,7 @@
> *
> */
>
> +#include "linux/security.h"
> #include
> #include
> #include
> @@ -1443,6 +1444,10 @@ static int vduse_dev_open(struct inode *inode, struct
> file *file)
> if (dev->connected)
> goto unlock;
>
> + ret = -EPERM;
> + if (security_vduse_dev_open(dev->device_id))
> + goto unlock;
> +
> ret = 0;
> dev->connected = true;
> file->private_data = dev;
> @@ -1655,6 +1660,9 @@ static int vduse_destroy_dev(char *name)
> if (!dev)
> return -EINVAL;
>
> + if (security_vduse_dev_destroy(dev->device_id))
> + return -EPERM;
> +
> mutex_lock(&dev->lock);
> if (dev->vdev || dev->connected) {
> mutex_unlock(&dev->lock);
> @@ -1819,6 +1827,10 @@ static int vduse_create_dev(struct vduse_dev_config
> *config,
> int ret;
> struct vduse_dev *dev;
>
> + ret = -EPERM;
> + if (security_vduse_dev_create(config->device_id))
> + goto err;
> +
> ret = -EEXIST;
> if (vduse_find_dev(config->name))
> goto err;
> diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
> index ac962c4cb44b..0b3999ab3264 100644
> --- a/include/linux/lsm_hook_defs.h
> +++ b/include/linux/lsm_hook_defs.h
> @@ -419,3 +419,7 @@ LSM_HOOK(int, 0, uring_override_creds, const struct cred
> *new)
> LSM_HOOK(int, 0, uring_sqpoll, void)
> LSM_HOOK(int, 0, uring_cmd, struct io_uring_cmd *ioucmd)
> #endif /* CONFIG_IO_URING */
> +
> +LSM_HOOK(int, 0, vduse_dev_create, u32 device_id)
> +LSM_HOOK(int, 0, vduse_dev_destroy, u32 device_id)
> +LSM_HOOK(int, 0, vduse_dev_open, u32 device_id)
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 5f16eecde00b..a650c500f841 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -484,6 +484,9 @@ int security_inode_notifysecctx(struct inode *inode, void
> *ctx, u32 ctxlen);
> int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen);
> int security_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen);
> int security_locked_down(enum lockdown_reason what);
> +int security_vduse_dev_create(u32 device_id);
> +int security_vduse_dev_destroy(u32 device_id);
> +int security_vduse_dev_open(u32 device_id);
> #else /* CONFIG_SECURITY */
>
> static inline int call_blocking_lsm_notifier(enum lsm_event event, void
> *data)
> @@ -1395,6 +1398,18 @@ static inline int security_locked_down(enum
> lockdown_reason what)
> {
> return 0;
> }
> +static inline int security_vduse_dev_create(u32 device_id)
> +{
> + return 0;
> +}
> +static inline int security_vduse_dev_destroy(u32 device_id)
> +{
> + return 0;
> +}
> +static inline int security_vduse_dev_open(u32 device_id)
> +{
> + return 0;
> +}
> #endif /* CONFIG_SECURITY */
>
> #if defined(CONFIG_SECURITY) && defined(CONFIG_WATCH_QUEUE)
> diff --git a/security/security.c b/security/security.c
> index 23b129d482a7..8d7d4d2eca0b 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -5337,3 +5337,45 @@ int security_uring_cmd(struct io_uring_cmd *ioucmd)
> return call_int_hook(uring_cmd, 0, ioucmd);
> }
> #endif /* CONFIG_IO_URING */
> +
> +/**
> + * security_vduse_dev_create() - Check if a VDUSE device type creation is
> allowed
> + * @device_id: the Virtio device ID
> + *
> + * Check whether the Virtio device creation is allowed
> + *
> + * Return: Returns 0 if permission is granted.
> + */
> +int security_vduse_dev_create(u32 device_id)
> +{
> + return call_int_hook(vduse_dev_create, 0, device_id);
> +}
> +EXPORT_SYMBOL(security_vduse_dev_create);
> +
> +/**
> + * security_vduse_dev_destroy() - Check if a VDUSE device type destruction
> is allowed
> + * @device_id: the Virtio device ID
> + *
> + * Check whether the Virtio device destruction is allowed
> + *
> + * Return: Returns 0 if permission is granted.
> + */
> +int security_vduse
[PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
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.
Signed-off-by: Maxime Coquelin
---
drivers/vdpa/vdpa_user/vduse_dev.c | 12 +++
include/linux/lsm_hook_defs.h | 4 +++
include/linux/security.h| 15
security/security.c | 42 ++
security/selinux/hooks.c| 55 +
security/selinux/include/classmap.h | 2 ++
6 files changed, 130 insertions(+)
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c
b/drivers/vdpa/vdpa_user/vduse_dev.c
index 0243dee9cf0e..ca64eac11ddb 100644
--- a/drivers/vdpa/vdpa_user/vduse_dev.c
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -8,6 +8,7 @@
*
*/
+#include "linux/security.h"
#include
#include
#include
@@ -1443,6 +1444,10 @@ static int vduse_dev_open(struct inode *inode, struct
file *file)
if (dev->connected)
goto unlock;
+ ret = -EPERM;
+ if (security_vduse_dev_open(dev->device_id))
+ goto unlock;
+
ret = 0;
dev->connected = true;
file->private_data = dev;
@@ -1655,6 +1660,9 @@ static int vduse_destroy_dev(char *name)
if (!dev)
return -EINVAL;
+ if (security_vduse_dev_destroy(dev->device_id))
+ return -EPERM;
+
mutex_lock(&dev->lock);
if (dev->vdev || dev->connected) {
mutex_unlock(&dev->lock);
@@ -1819,6 +1827,10 @@ static int vduse_create_dev(struct vduse_dev_config
*config,
int ret;
struct vduse_dev *dev;
+ ret = -EPERM;
+ if (security_vduse_dev_create(config->device_id))
+ goto err;
+
ret = -EEXIST;
if (vduse_find_dev(config->name))
goto err;
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index ac962c4cb44b..0b3999ab3264 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -419,3 +419,7 @@ LSM_HOOK(int, 0, uring_override_creds, const struct cred
*new)
LSM_HOOK(int, 0, uring_sqpoll, void)
LSM_HOOK(int, 0, uring_cmd, struct io_uring_cmd *ioucmd)
#endif /* CONFIG_IO_URING */
+
+LSM_HOOK(int, 0, vduse_dev_create, u32 device_id)
+LSM_HOOK(int, 0, vduse_dev_destroy, u32 device_id)
+LSM_HOOK(int, 0, vduse_dev_open, u32 device_id)
diff --git a/include/linux/security.h b/include/linux/security.h
index 5f16eecde00b..a650c500f841 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -484,6 +484,9 @@ int security_inode_notifysecctx(struct inode *inode, void
*ctx, u32 ctxlen);
int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen);
int security_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen);
int security_locked_down(enum lockdown_reason what);
+int security_vduse_dev_create(u32 device_id);
+int security_vduse_dev_destroy(u32 device_id);
+int security_vduse_dev_open(u32 device_id);
#else /* CONFIG_SECURITY */
static inline int call_blocking_lsm_notifier(enum lsm_event event, void *data)
@@ -1395,6 +1398,18 @@ static inline int security_locked_down(enum
lockdown_reason what)
{
return 0;
}
+static inline int security_vduse_dev_create(u32 device_id)
+{
+ return 0;
+}
+static inline int security_vduse_dev_destroy(u32 device_id)
+{
+ return 0;
+}
+static inline int security_vduse_dev_open(u32 device_id)
+{
+ return 0;
+}
#endif /* CONFIG_SECURITY */
#if defined(CONFIG_SECURITY) && defined(CONFIG_WATCH_QUEUE)
diff --git a/security/security.c b/security/security.c
index 23b129d482a7..8d7d4d2eca0b 100644
--- a/security/security.c
+++ b/security/security.c
@@ -5337,3 +5337,45 @@ int security_uring_cmd(struct io_uring_cmd *ioucmd)
return call_int_hook(uring_cmd, 0, ioucmd);
}
#endif /* CONFIG_IO_URING */
+
+/**
+ * security_vduse_dev_create() - Check if a VDUSE device type creation is
allowed
+ * @device_id: the Virtio device ID
+ *
+ * Check whether the Virtio device creation is allowed
+ *
+ * Return: Returns 0 if permission is granted.
+ */
+int security_vduse_dev_create(u32 device_id)
+{
+ return call_int_hook(vduse_dev_create, 0, device_id);
+}
+EXPORT_SYMBOL(security_vduse_dev_create);
+
+/**
+ * security_vduse_dev_destroy() - Check if a VDUSE device type destruction is
allowed
+ * @device_id: the Virtio device ID
+ *
+ * Check whether the Virtio device destruction is allowed
+ *
+ * Return: Returns 0 if permission is granted.
+ */
+int security_vduse_dev_destroy(u32 device_id)
+{
+ return call_int_hook(vduse_dev_destroy, 0, device_id);
+}
+EXPORT_SYMBOL(security_vduse_dev_destroy);
+
+/**
+ * security_vduse_dev_open() - Check if a VDUSE device type opening is allowed
+ * @device_id: the Virtio device ID
+ *
+ * Check whether the Virtio device opening is allowed
+ *
+ * Return: Returns 0 if permission is granted.
+ */
+int security_vduse_dev_open(u3
