Received: by 2002:a05:7412:8d06:b0:f9:332d:97f1 with SMTP id bj6csp86412rdb; Mon, 18 Dec 2023 09:33:56 -0800 (PST) X-Google-Smtp-Source: AGHT+IFo757590Oke9SJTVHin2Jo+WIyHkiiQY1XODnKmXD1x3a8I48ULK5GA3frqECmZzx+qY+h X-Received: by 2002:a17:906:2655:b0:a1b:5f36:24da with SMTP id i21-20020a170906265500b00a1b5f3624damr7127524ejc.121.1702920836384; Mon, 18 Dec 2023 09:33:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702920836; cv=none; d=google.com; s=arc-20160816; b=fMwPKD6hcxcD3UvUoUaTbASflgFL8k2aS6rXAvijbqSI0TyWCwAyi4r+8jU+Zw+SuM VBukHM6a0btvBhvluZO50csvCEoRBjmJsEVf1xpupjwdVfNQssNhZiSdExHi67EWeauR E0rOzCDMfE2TgQuMSGOPVBmxBKGb9GTZspelSdw1ODZae+YvxtaRAhOkmlNPzyZ8/bKr KILIzRT+spQ46Q6CPRd4qTdbnHc+YGC8ZKOSPy3YsWpp3msx6QlNaSEPgd7Y8Pl9jLdR ARAOUjhnymep4PkhuGYtI55YjLVQRzNHQLX7ZzRTFBJ6rxlmn9jhcT21kEbBFWrU7Wv1 bPjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence:dkim-signature; bh=vrrdb72hryOiQh+u7nxbNRimC+6/pwn0HNgKp0aqgVU=; fh=CsOhC4UwnjS+yoJwEkGaSLnpjG5BCPbz8ECuP5+2Yig=; b=KrRc+sF3kUMgHxrd4h9NAXUm3U7et96eOr9GQRgceytWN5Zkwrlu0zvMXmoxEb2cia FKiHX7BZzkV1QO1ul+vd/OUlWtNdaAZarvffxq6/+gd+82YPLPm7XgKoYGYHP+LnMfmg 7HM64h6TJmD6qfjDqqGOBuvy9ofV1Xco/znqt2x/+EOuxVh2vwL8agVmGCLk10YGhugU kx45bZg4DiNLFiZknU3WGiEU1hpwSHhFV0Lu1vG2Mh3hSLOv73h5z6iaN1sL8I70mwd1 8ItcMpq4ctxsremxx0XL5cbmBl7/UQoZKHfphvpNucKbBBUtGDkKQlnCBPPMOZmTGMg+ 4gNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=BxAf7ckF; spf=pass (google.com: domain of linux-kernel+bounces-4176-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4176-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id lr2-20020a170906fb8200b00a1d991c3a06si6309643ejb.298.2023.12.18.09.33.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Dec 2023 09:33:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-4176-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=BxAf7ckF; spf=pass (google.com: domain of linux-kernel+bounces-4176-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4176-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 098CE1F2258C for ; Mon, 18 Dec 2023 17:33:56 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5C2F15BFA2; Mon, 18 Dec 2023 17:33:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BxAf7ckF" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 64C1A1E4BF; Mon, 18 Dec 2023 17:33:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-6ceb2501f1bso3124281b3a.0; Mon, 18 Dec 2023 09:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702920824; x=1703525624; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vrrdb72hryOiQh+u7nxbNRimC+6/pwn0HNgKp0aqgVU=; b=BxAf7ckFxtZ4xRObZAMnxTiRjsgMwwG38vCQk/ecdSs+Gz7X4R57uJVbF1YQB1kVsX Ovh1XKTdVpmioOuWQ6GZK89/uB4BvUAZjkdCJ+cwQiiSzlo23kw+MVBGzG76QYMwKLMy 1qak+/arYLezUH3lTLEVS9j0a7yURLS47xkWL2CadmQ4zkpv6VjwctX/UWsCE08qF4+l R3Vs84iVniY9QzUz+cPy1wNdOfA31xI073rAxQ4ysBQt8I3EIkcSV9/LHpZClt7TH1x1 uPdsCC0i/fc1EvmZJjOPmLoCorwSmrbLpE6Va73E3tP6AaUfP7+68J00+eCvOYpI8lCa VXcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702920825; x=1703525625; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vrrdb72hryOiQh+u7nxbNRimC+6/pwn0HNgKp0aqgVU=; b=sldS7+ZM8Ic83AYzHo6Bj+/Nk2TLvr9+zOhO1ZoxPU7UZsrF+QQKgjn9WbbmLebgrX 89hYXkZ/CraRr3XAOokMjvp841f7mL5goTR4l6YTfNyYFgw0rBF7Hor3lZMiorHltKyp bz9+6P77cokWAl1ZtHoOiT12XDTgrory9HDkPh16130/jtSyBMGJFpdmb3/qWt39pAZK +SmETHzxsC3nf6xhxRokCjjIS5lJgQuh4KeX3kSY0+JCwLHcoCsGJSAzU+uAF9B4MnWz FJl+2RdHOHgJzrnuR/ZG6osQNCLQN9Cc1juTfn916eL5Ll+3NQ1hgW4qb7TaFDC90zcM UmdQ== X-Gm-Message-State: AOJu0Yzu6dTk5Bdkz4GslQnxKDCn75vJrwqzx4tIqFK7i0z+dWfz/F6X VimdZE2rQhFMwb68Gab1tm03VJEnrAMqn+32vnA= X-Received: by 2002:a05:6a00:c81:b0:6cb:a2f4:8579 with SMTP id a1-20020a056a000c8100b006cba2f48579mr19678291pfv.15.1702920824664; Mon, 18 Dec 2023 09:33:44 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20231212131712.1816324-1-maxime.coquelin@redhat.com> <20231212131712.1816324-5-maxime.coquelin@redhat.com> In-Reply-To: From: Stephen Smalley Date: Mon, 18 Dec 2023 12:33:33 -0500 Message-ID: Subject: Re: [PATCH v5 4/4] vduse: Add LSM hook to check Virtio device type To: Maxime Coquelin , Ondrej Mosnacek Cc: mst@redhat.com, jasowang@redhat.com, xuanzhuo@linux.alibaba.com, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.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, casey@schaufler-ca.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 18, 2023 at 12:21=E2=80=AFPM Stephen Smalley wrote: > > On Tue, Dec 12, 2023 at 8:17=E2=80=AFAM Maxime Coquelin > wrote: > > > > This patch introduces a LSM hook for devices creation, > > destruction (ioctl()) and opening (open()) operations, > > checking the application is allowed to perform these > > operations for the Virtio device type. > > Can you explain why the existing LSM hooks and SELinux implementation > are not sufficient? We already control the ability to open device > nodes via selinux_inode_permission() and selinux_file_open(), and can > support fine-grained per-cmd ioctl checking via selinux_file_ioctl(). > And it should already be possible to label these nodes distinctly > through existing mechanisms (file_contexts if udev-created/labeled, > genfs_contexts if kernel-created). What exactly can't you do today > that this hook enables? (added Ondrej to the distribution; IMHO we should swap him into MAINTAINERS in place of Eric Paris since Eric has long-since moved on from SELinux and Ondrej serves in that capacity these days) Other items to consider: - If vduse devices are created using anonymous inodes, then SELinux grew a general facility for labeling and controlling the creation of those via selinux_inode_init_security_anon(). - You can encode information about the device into its SELinux type that then allows you to distinguish things like net vs block based on the device's SELinux security context rather than encoding that in the permission bits. - If you truly need new LSM hooks (which you need to prove first), then you should pass some usable information about the object in question to allow SELinux to find a security context for it. Like an inode associated with the device, for example.