From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 351C0C43217 for ; Mon, 28 Nov 2022 11:00:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230461AbiK1LAW (ORCPT ); Mon, 28 Nov 2022 06:00:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230463AbiK1LAM (ORCPT ); Mon, 28 Nov 2022 06:00:12 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8EBC114D3E for ; Mon, 28 Nov 2022 02:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669633156; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=peJt9P7iZNSaiwA/6aObimwPef1VvCVnc1Ve9gvBOC8=; b=BLroK5vUWzY++k7DnvQyAHG8BvtAmGCJL/btX31FkW/XyUR8PyCaN8NEBvy2MudD+J0RS5 lkkUnvyXYvph3VGvg+W5NGvnv3AvGh6+Q1IGhhXoeQAtiSFR99malK0sZPcMkxLK+PkiKD 6BXAya0nGon3NoAnciDaET50EcH+tFE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-347-0pe5WdpIPcOmbJGqYwPiCw-1; Mon, 28 Nov 2022 05:59:13 -0500 X-MC-Unique: 0pe5WdpIPcOmbJGqYwPiCw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D15B1811E75; Mon, 28 Nov 2022 10:59:12 +0000 (UTC) Received: from T590 (ovpn-8-18.pek2.redhat.com [10.72.8.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B8D1E40C6EC2; Mon, 28 Nov 2022 10:59:07 +0000 (UTC) Date: Mon, 28 Nov 2022 18:59:02 +0800 From: Ming Lei To: Joel Granados Cc: Paul Moore , Luis Chamberlain , Kanchan Joshi , ddiss@suse.de, linux-security-module@vger.kernel.org, io-uring@vger.kernel.org Subject: Re: [RFC 1/1] Use ioctl selinux callback io_uring commands that implement the ioctl op convention Message-ID: References: <20221116125051.3338926-2-j.granados@samsung.com> <20221116173821.GC5094@test-zns> <20221117094004.b5l64ipicitphkun@localhost> <20221128101329.lcn3bimihmtwsqqm@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221128101329.lcn3bimihmtwsqqm@localhost> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Mon, Nov 28, 2022 at 11:13:29AM +0100, Joel Granados wrote: > On Tue, Nov 22, 2022 at 10:04:03PM +0800, Ming Lei wrote: > > On Mon, Nov 21, 2022 at 04:05:37PM -0500, Paul Moore wrote: > > > On Mon, Nov 21, 2022 at 2:53 PM Luis Chamberlain wrote: > > > > On Thu, Nov 17, 2022 at 05:10:07PM -0500, Paul Moore wrote: > > > > > On Thu, Nov 17, 2022 at 4:40 AM Joel Granados wrote: > > > > > > On Wed, Nov 16, 2022 at 02:21:14PM -0500, Paul Moore wrote: > > > > > > > > > > ... > > > > > > > > > > > > * As we discussed previously, the real problem is the fact that we are > > > > > > > missing the necessary context in the LSM hook to separate the > > > > > > > different types of command targets. With traditional ioctls we can > > > > > > > look at the ioctl number and determine both the type of > > > > > > > device/subsystem/etc. as well as the operation being requested; there > > > > > > > is no such information available with the io_uring command > > > > > > > passthrough. In this sense, the io_uring command passthrough is > > > > > > > actually worse than traditional ioctls from an access control > > > > > > > perspective. Until we have an easy(ish)[1] way to determine the > > > > > > > io_uring command target type, changes like the one suggested here are > > > > > > > going to be doomed as each target type is free to define their own > > > > > > > io_uring commands. > > > > > > > > > > > > The only thing that comes immediately to mind is that we can have > > > > > > io_uring users define a function that is then passed to the LSM > > > > > > infrastructure. This function will have all the logic to give relative > > > > > > context to LSM. It would be general enough to fit all the possible commands > > > > > > and the logic would be implemented in the "drivers" side so there is no > > > > > > need for LSM folks to know all io_uring users. > > > > > > > > > > Passing a function pointer to the LSM to fetch, what will likely be > > > > > just a constant value, seems kinda ugly, but I guess we only have ugly > > > > > options at this point. > > > > > > > > I am not sure if this helps yet, but queued on modules-next we now have > > > > an improvement in speed of about 1500x for kallsyms_lookup_name(), and > > > > so symbol lookups are now fast. Makes me wonder if a type of special > > > > export could be drawn up for specific calls which follow a structure > > > > and so the respective lsm could be inferred by a prefix instead of > > > > placing the calls in-place. Then it would not mattter where a call is > > > > used, so long as it would follow a specific pattern / structure with > > > > all the crap you need on it. > > > > > > I suspect we may be talking about different things here, I don't think > > > the issue is which LSM(s) may be enabled, as the call is to > > > security_uring_cmd() regardless. I believe the issue is more of how > > > do the LSMs determine the target of the io_uring command, e.g. nvme or > > > ublk. > > > > > > My understanding is that Joel was suggesting a change to the LSM hook > > > to add a function specific pointer (presumably defined as part of the > > > file_operations struct) that could be called by the LSM to determine > > > the target. > > > > > > Although now that I'm looking again at the file_operations struct, I > > > wonder if we would be better off having the LSMs inspect the > > > file_operations::owner field, potentially checking the module::name > > > field. It's a little painful in the sense that it is potentially > > > multiple strcmp() calls for each security_uring_cmd() call, but I'm > > > not sure the passed function approach would be much better. Do we > > > have a consistent per-module scalar value we can use instead of a > > > character string? > > > > In future there may be more uring_cmd kernel users, maybe we need to > > consider to use one reserved field in io_uring_sqe for describing the > > target type if it is one must for security subsystem, and this way > > will be similar with traditional ioctl which encodes this kind of > > info in command type. > This is of course another option. I was a bit reluctant to start the > discussion with this implementation, but now that you have brought it up > I can come up with an initial RFC and we can add it to the mix of > possibilities. > > Would you just add it to the end of the struct? or what reserved field > are you referring to? io_uring_sqe is uapi, so you can't add any field to sqe, and '__pad1' could be best field for carrying this info, given it is close to 'cmd_op', and 'u8' should be enough for storing target type info. thanks, Ming