Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp13881312pxu; Mon, 4 Jan 2021 07:03:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJwzgOmcnPMjIII1BuJSKNMl5RAGq8yulDUzMWBy2JgwV9d7ViZEVnVX4eQqOQ+vVlw1uPDg X-Received: by 2002:a17:906:1291:: with SMTP id k17mr68116092ejb.288.1609772612993; Mon, 04 Jan 2021 07:03:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609772612; cv=none; d=google.com; s=arc-20160816; b=x14tRqRG8wT3vCb7e3hwGP/GJv9C2ZdLsP0SlJIF7WoNw3Qw72YpVvw/vTE0/SYdfy p5xx3/5L4oc5U+gclGIOtt0K7boLwrPbyA0uGmr2c0mo3J25Az3TnnXI/KS8RtqopbF5 SNm44Jc8EjQyXVBEP7zXHNmZkN9NGiD5Q7ATW+LWLylHEy7Kz3dB7oI6Hj9JM/GZsuVZ jkUWvGps+GebrvoWXoGRQhasvNX8rF4z8xSpnVemGREq0UosjU5S4gahv66KHVzEyXC8 NuT5sh5B40FQ9Gwj+U6lcPZeqAoznMM3mdShJcfqERbfqlDxS+rHFM0TPG1j3fML0VCh B9/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:in-reply-to :date:references:subject:cc:to:from:dkim-signature:dkim-filter; bh=2b1CZ0lgQc1RU0te5KlqMCa54V4lwcogGB9R2zN1w/A=; b=goGaL3YO4Xy3rvXPth2GH95IB+c8Gn/hHhd90jQ1LF3hfm9rG+cKOObBkjD0TJEEvW qJTkKWmX29WaZNsZ+j/FlgAmbv3WL4sX0tKinJIldr3yvesK2/WWfoKR7V1RZyfLdo3c SsoO73EcGFeq9ZEL8GrAaN6C0btG/Om4D6BtiNbNS+FclzAX/D4LK/PaW8RMt8aL91yC WHmEpYiwtB4WkfOd+uKKxuze9VYOQT/339LNKWKpGeWP11AKX9I5h5w+MT0Ot0LiuKtF b1C4+O/t6l90YsZ8vo8gISyCk7bv4CJupN4TP6wZvXKz6CmaREnh5ZrWcq/WAWz1dbRk Dl0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@defensec.nl header.s=default header.b=momepofX; spf=pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=selinux-refpolicy-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e21si26846701edj.402.2021.01.04.07.03.27; Mon, 04 Jan 2021 07:03:32 -0800 (PST) Received-SPF: pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@defensec.nl header.s=default header.b=momepofX; spf=pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=selinux-refpolicy-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727431AbhADPBq (ORCPT + 18 others); Mon, 4 Jan 2021 10:01:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36642 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727307AbhADPBq (ORCPT ); Mon, 4 Jan 2021 10:01:46 -0500 Received: from agnus.defensec.nl (agnus.defensec.nl [IPv6:2001:985:d55d::711]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E081DC061796 for ; Mon, 4 Jan 2021 07:00:57 -0800 (PST) Received: from brutus (brutus.defensec.nl [IPv6:2001:985:d55d::438]) by agnus.defensec.nl (Postfix) with ESMTPSA id 677562A12B1; Mon, 4 Jan 2021 16:00:55 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 agnus.defensec.nl 677562A12B1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=defensec.nl; s=default; t=1609772457; bh=2b1CZ0lgQc1RU0te5KlqMCa54V4lwcogGB9R2zN1w/A=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=momepofXbgXOrkC3r85zFhtbRZicN8hQhrUGNbuoXHL9dxJs6B6/fe72m34eML85g R3SNevZaxzLYBJn0rO7n8WrViHNURPDfxtLa6m7ByMfrRf6vX0CgFBHzGdVyoaRkf2 sTk7mvRVPTbTJWVty75H5nqMjASPSAoI/8f1Ew2k= From: Dominick Grift To: Chris PeBenito Cc: Russell Coker , selinux-refpolicy@vger.kernel.org Subject: Re: machinectl shell policy References: <8322849.62pqQp6Oog@liv> <1723812.Y751QtlBzf@liv> <5735537.jZnottUgFY@liv> Date: Mon, 04 Jan 2021 16:00:52 +0100 In-Reply-To: (Chris PeBenito's message of "Mon, 4 Jan 2021 09:48:42 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org Chris PeBenito writes: > On 12/25/20 4:16 AM, Russell Coker wrote: >> On Friday, 25 December 2020 6:58:41 PM AEDT Dominick Grift wrote: >>> Russell Coker writes: >>>> On Thursday, 24 December 2020 7:37:50 PM AEDT Dominick Grift wrote: >>>>>> To enable "machinectl shell" on recent versions of systemd we need >>>>>> something like the above policy (which is not complete or ideal, still >>>>>> doesn't work so no point polishing it) and something for the below. >>>>>> What >>>>>> is the below about? >>>>> >>>>> this should be thoroughly addressed. machined creates a login pty that >>>>> gets relabeled on login as per type_change rules. >>>> >>>> Currently it's not being relabeled on Debian, but that's a separate issue. >>> >>> Maybe the required type_change rules arent present? >> Here is all the policy to make it work. Maybe we should have a type >> like >> system_dbusd_devpts_t for this. This is not policy for inclusion, this is >> policy to discuss before writing that policy. >> term_user_pty(user_systemd_t, user_devpts_t) >> term_login_pty(devpts_t) >> allow user_systemd_t user_devpts_t:chr_file rw_file_perms; >> # for machinectl shell >> allow sysadm_t systemd_machined_t:dbus send_msg; >> systemd_manage_userdb_runtime_dirs(systemd_machined_t) >> systemd_manage_userdb_runtime_sock_files(systemd_machined_t) >> term_use_ptmx(systemd_machined_t) >> dev_getattr_fs(systemd_machined_t) >> term_getattr_pty_fs(systemd_machined_t) >> allow systemd_machined_t sysadm_t:dbus send_msg; >> allow systemd_machined_t devpts_t:chr_file rw_file_perms; >> allow system_dbusd_t systemd_machined_t:fd use; >> allow system_dbusd_t devpts_t:chr_file { read write }; >> allow system_dbusd_t ptmx_t:chr_file { read write }; >> allow sysadm_t systemd_machined_t:fd use; >> allow user_systemd_t shell_exec_t:file entrypoint; > > The pty stuff seems to make sense, but I'm curious why there is a > transition into user_systemd_t for the shell. The policy above is referencing "devpts_t", that is sub-optimal. there shouldnt be any pty chr files with the devpts_t filesystem type > >> allow user_systemd_t systemd_machined_t:fd use; >> allow user_systemd_t self:process signal; >> allow user_t systemd_machined_t:fd use; >> allow user_t user_systemd_t:fifo_file { getattr write }; >> allow user_t init_t:process signal; > > > >>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892001 >>>> >>>> We have work in progress on dbus-broker in Debian. Would it make sense to >>>> only support dbus-broker in SE Linux policy? Being forced to use only 1 >>>> of >>>> the 2 dbus programs (and the newer and faster 1 of the 2) is a very small >>>> trade-off, smaller than some of the other trade-offs for running SE Linux. > > I'd prefer to keep both unless it becomes onerous. > > >>> should probably be able to support both (conditionally) but could get messy >> Currently we have a heap of ifdef systemd in the policy, as probably >> the only >> people not wanting dbus-broker will be the ones not wanting systemd we could >> include it in the same ifdef rules. > > The "else" of the ifdef can work. -- gpg --locate-keys dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift