All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
	jasowang@redhat.com, xuanzhuo@linux.alibaba.com,
	paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com,
	stephen.smalley.work@gmail.com, eparis@parisplace.org,
	xieyongji@bytedance.com,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
	david.marchand@redhat.com, lulu@redhat.com
Subject: Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
Date: Fri, 3 Nov 2023 04:04:50 -0400	[thread overview]
Message-ID: <20231103040224-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <598eb8df-0f5f-4f21-8c34-f54ecbbcaca2@redhat.com>

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-mst@kernel.org/
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > 


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>
Cc: xuanzhuo@linux.alibaba.com, paul@paul-moore.com, lulu@redhat.com,
	selinux@vger.kernel.org, linux-kernel@vger.kernel.org,
	jmorris@namei.org, virtualization@lists.linux-foundation.org,
	xieyongji@bytedance.com, linux-security-module@vger.kernel.org,
	Casey Schaufler <casey@schaufler-ca.com>,
	eparis@parisplace.org, david.marchand@redhat.com,
	stephen.smalley.work@gmail.com, serge@hallyn.com
Subject: Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type
Date: Fri, 3 Nov 2023 04:04:50 -0400	[thread overview]
Message-ID: <20231103040224-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <598eb8df-0f5f-4f21-8c34-f54ecbbcaca2@redhat.com>

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-mst@kernel.org/
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > 

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2023-11-03  8:05 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-20 15:58 [PATCH v4 0/4] vduse: add support for networking devices Maxime Coquelin
2023-10-20 15:58 ` Maxime Coquelin
2023-10-20 15:58 ` [PATCH v4 1/4] vduse: validate block features only with block devices Maxime Coquelin
2023-10-20 15:58   ` Maxime Coquelin
2023-10-20 22:07   ` Casey Schaufler
2023-10-20 22:07     ` Casey Schaufler
2023-10-23  7:35     ` Maxime Coquelin
2023-10-23  7:35       ` Maxime Coquelin
2023-10-20 15:58 ` [PATCH v4 2/4] vduse: enable Virtio-net device type Maxime Coquelin
2023-10-20 15:58   ` Maxime Coquelin
2023-10-20 15:58 ` [PATCH v4 3/4] vduse: Temporarily disable control queue features Maxime Coquelin
2023-10-20 15:58   ` Maxime Coquelin
2023-10-23  3:08   ` Jason Wang
2023-10-23  3:08     ` Jason Wang
2023-10-23  7:43     ` Maxime Coquelin
2023-10-23  7:43       ` Maxime Coquelin
2023-10-20 15:58 ` [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type Maxime Coquelin
2023-10-20 15:58   ` Maxime Coquelin
2023-10-20 22:20   ` Casey Schaufler
2023-10-20 22:20     ` Casey Schaufler
2023-10-23  7:28     ` Maxime Coquelin
2023-10-23  7:28       ` Maxime Coquelin
2023-10-23 15:13       ` Casey Schaufler
2023-10-23 15:13         ` Casey Schaufler
2023-10-24  9:49         ` Maxime Coquelin
2023-10-24  9:49           ` Maxime Coquelin
2023-10-24 15:30           ` Casey Schaufler
2023-10-24 15:30             ` Casey Schaufler
2023-11-02 17:56             ` Maxime Coquelin
2023-11-02 17:56               ` Maxime Coquelin
2023-11-02 18:59               ` Michael S. Tsirkin
2023-11-02 18:59                 ` Michael S. Tsirkin
2023-11-03  7:55                 ` Maxime Coquelin
2023-11-03  7:55                   ` Maxime Coquelin
2023-11-03  8:04                   ` Michael S. Tsirkin [this message]
2023-11-03  8:04                     ` Michael S. Tsirkin
2023-10-23  3:09   ` Jason Wang
2023-10-23  3:09     ` Jason Wang
2023-11-08  2:31   ` Paul Moore
2023-12-08 11:01     ` Maxime Coquelin
2023-12-08 11:05       ` Michael S. Tsirkin
2023-12-08 12:23         ` Maxime Coquelin
2023-12-08 12:26           ` Michael S. Tsirkin
2023-12-08 12:59             ` Maxime Coquelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231103040224-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=casey@schaufler-ca.com \
    --cc=david.marchand@redhat.com \
    --cc=eparis@parisplace.org \
    --cc=jasowang@redhat.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=stephen.smalley.work@gmail.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xieyongji@bytedance.com \
    --cc=xuanzhuo@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.