From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>, aconole@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 13:59:45 +0100 [thread overview]
Message-ID: <f539bdcd-1008-410d-95a4-92be6c851c08@redhat.com> (raw)
In-Reply-To: <20231208072649-mutt-send-email-mst@kernel.org>
On 12/8/23 13:26, Michael S. Tsirkin wrote:
> 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 :)
>
Adding Aaron, our go-to person for SELinux-related topics for OVS, but I
think we don't need to do relabeling for VDUSE chardevs.
Aaron, do you confirm?
Maxime
prev parent reply other threads:[~2023-12-08 13:00 UTC|newest]
Thread overview: 25+ 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 ` [PATCH v4 1/4] vduse: validate block features only with block devices Maxime Coquelin
2023-10-20 22:07 ` Casey Schaufler
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 ` [PATCH v4 3/4] vduse: Temporarily disable control queue features Maxime Coquelin
2023-10-23 3:08 ` Jason Wang
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 22:20 ` Casey Schaufler
2023-10-23 7:28 ` Maxime Coquelin
2023-10-23 15:13 ` Casey Schaufler
2023-10-24 9:49 ` Maxime Coquelin
2023-10-24 15:30 ` Casey Schaufler
2023-11-02 17:56 ` Maxime Coquelin
2023-11-02 18:59 ` Michael S. Tsirkin
2023-11-03 7:55 ` Maxime Coquelin
2023-11-03 8:04 ` Michael S. Tsirkin
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 [this message]
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=f539bdcd-1008-410d-95a4-92be6c851c08@redhat.com \
--to=maxime.coquelin@redhat.com \
--cc=aconole@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=mst@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®