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: Paul Moore <paul@paul-moore.com>,
	Casey Schaufler <casey@schaufler-ca.com>,
	jasowang@redhat.com, xuanzhuo@linux.alibaba.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, 8 Dec 2023 07:26:59 -0500	[thread overview]
Message-ID: <20231208072649-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <a5faf263-d998-4845-952f-9c8dc1d4609f@redhat.com>

On Fri, Dec 08, 2023 at 01:23:00PM +0100, Maxime Coquelin wrote:
> 
> 
> On 12/8/23 12:05, Michael S. Tsirkin wrote:
> > On Fri, Dec 08, 2023 at 12:01:15PM +0100, Maxime Coquelin wrote:
> > > Hello Paul,
> > > 
> > > On 11/8/23 03:31, Paul Moore wrote:
> > > > On Oct 20, 2023 "Michael S. Tsirkin" <mst@redhat.com> 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 <maxime.coquelin@redhat.com>
> > > > > ---
> > > > >    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(+)
> > > > 
> > > > My apologies for the late reply, I've been trying to work my way through
> > > > the review backlog but it has been taking longer than expected; comments
> > > > below ...
> > > 
> > > No worries, I have also been busy these days.
> > > 
> > > > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > > > > index 2aa0e219d721..65d9262a37f7 100644
> > > > > --- a/security/selinux/hooks.c
> > > > > +++ b/security/selinux/hooks.c
> > > > > @@ -21,6 +21,7 @@
> > > > >     *  Copyright (C) 2016 Mellanox Technologies
> > > > >     */
> > > > > +#include "av_permissions.h"
> > > > >    #include <linux/init.h>
> > > > >    #include <linux/kd.h>
> > > > >    #include <linux/kernel.h>
> > > > > @@ -92,6 +93,7 @@
> > > > >    #include <linux/fsnotify.h>
> > > > >    #include <linux/fanotify.h>
> > > > >    #include <linux/io_uring.h>
> > > > > +#include <uapi/linux/virtio_ids.h>
> > > > >    #include "avc.h"
> > > > >    #include "objsec.h"
> > > > > @@ -6950,6 +6952,56 @@ static int selinux_uring_cmd(struct io_uring_cmd *ioucmd)
> > > > >    }
> > > > >    #endif /* CONFIG_IO_URING */
> > > > > +static int vduse_check_device_type(u32 sid, u32 device_id)
> > > > > +{
> > > > > +	u32 requested;
> > > > > +
> > > > > +	if (device_id == VIRTIO_ID_NET)
> > > > > +		requested = VDUSE__NET;
> > > > > +	else if (device_id == VIRTIO_ID_BLOCK)
> > > > > +		requested = VDUSE__BLOCK;
> > > > > +	else
> > > > > +		return -EINVAL;
> > > > > +
> > > > > +	return avc_has_perm(sid, sid, SECCLASS_VDUSE, requested, NULL);
> > > > > +}
> > > > > +
> > > > > +static int selinux_vduse_dev_create(u32 device_id)
> > > > > +{
> > > > > +	u32 sid = current_sid();
> > > > > +	int ret;
> > > > > +
> > > > > +	ret = avc_has_perm(sid, sid, SECCLASS_VDUSE, VDUSE__DEVCREATE, NULL);
> > > > > +	if (ret)
> > > > > +		return ret;
> > > > > +
> > > > > +	return vduse_check_device_type(sid, device_id);
> > > > > +}
> > > > 
> > > > I see there has been some discussion about the need for a dedicated
> > > > create hook as opposed to using the existing ioctl controls.  I think
> > > > one important point that has been missing from the discussion is the
> > > > idea of labeling the newly created device.  Unfortunately prior to a
> > > > few minutes ago I hadn't ever looked at VDUSE so please correct me if
> > > > I get some things wrong :)
> > > > 
> > > >   From what I can see userspace creates a new VDUSE device with
> > > > ioctl(VDUSE_CREATE_DEV), which trigger the creation of a new
> > > > /dev/vduse/XXX device which will be labeled according to the udev
> > > > and SELinux configuration, likely with a generic udev label.  My
> > > > question is if we want to be able to uniquely label each VDUSE
> > > > device based on the process that initiates the device creation
> > > > with the call to ioctl()?  If that is the case, we would need a
> > > > create hook not only to control the creation of the device, but to
> > > > record the triggering process' label in the new device; this label
> > > > would then be used in subsequent VDUSE open and destroy operations.
> > > > The normal device file I/O operations would still be subject to the
> > > > standard SELinux file I/O permissions using the device file label
> > > > assigned by systemd/udev when the device was created.
> > > 
> > > I don't think we need a unique label for VDUSE devices, but maybe
> > > Michael thinks otherwise?
> > 
> > I don't know.
> > All this is consumed by libvirt, you need to ask these guys.
> 
> I think it is not consumed by libvirt, at least not in the usecases I
> have in mind. For networking devices, it will be consumed by OVS.
> 
> Maxime

OK, ovs then :)

-- 
MST


  reply	other threads:[~2023-12-08 12:27 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
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 [this message]
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=20231208072649-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.