Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4C506C282F6 for ; Mon, 21 Jan 2019 08:37:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 000C420823 for ; Mon, 21 Jan 2019 08:37:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ieee.org header.i=@ieee.org header.b="OrbAZXyE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728554AbfAUIhd (ORCPT ); Mon, 21 Jan 2019 03:37:33 -0500 Received: from mail-qt1-f194.google.com ([209.85.160.194]:44565 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729160AbfAUIhd (ORCPT ); Mon, 21 Jan 2019 03:37:33 -0500 Received: by mail-qt1-f194.google.com with SMTP id n32so22655127qte.11 for ; Mon, 21 Jan 2019 00:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uZrdP/FBTgGHiX4HIdD+QZqGU4o3Xe8e3CaTZKf++xk=; b=OrbAZXyEMgh5SawSWUm6a3Pty+dy3PMWOHZQ/7lC+pRVnvQuZCploWLSsE7hjwy06o Cb66zREFqTGBy7l0YgRv0Yo/FhS7qFFXu3ob29baURfa+K0uWFOnSXWO+PY4QHLgLaO1 2mpKPulxXQgF0YDukdF5hAMOX6T2agaypt+Ao= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uZrdP/FBTgGHiX4HIdD+QZqGU4o3Xe8e3CaTZKf++xk=; b=oD0lQJIDNJ6F0r9YYBFBBlwhcaLAzO0eLRQdzqV6dD/7Gl4zJnbNwGVPBIQyrxouef 2GZ44rKCzzRkhJt4nr6JIv6DY5iiS3B8QwJD3KmpX+o+/IQCYr6WYEXPWaLUjDYZEX2s EQFqhlGyUuGJEePW1axL3bX9bVNP6lEp2KnXcOhK0w+Pyy3HaohJlJV4aJ8FD06WN4Sx vYWvdRC6Wg2tzY1oGcoN/wKv9MJR2f+DbxnPhGn56wXkxtYY0jqZe15jQqQ2Br6i+4JR Ysb/i+YndiC52VBQynGBEBfa2Phf7K4NFGeFFV9bbH1aw9yGZCwIN0v7dAQ3yWF5agJs KRbg== X-Gm-Message-State: AJcUukdTWz5+5ecM28K+sXexn539PJX8E8Codhcd/IU6yYLjcePcnHYi S5lGtZbwsdNyD7sJoH6IUTSjIYrh1t4= X-Google-Smtp-Source: ALg8bN5YFAfBJY3KlM7l3D+JZPF+7bglhw1uRd6iPtUFgPEdeJZThTZ0sYqQWUtNVBrI5hO5+F5+3g== X-Received: by 2002:ac8:1add:: with SMTP id h29mr23938371qtk.258.1548020771738; Sun, 20 Jan 2019 13:46:11 -0800 (PST) Received: from [192.168.1.190] (pool-108-15-23-247.bltmmd.fios.verizon.net. [108.15.23.247]) by smtp.gmail.com with ESMTPSA id y2sm67842093qtb.88.2019.01.20.13.46.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Jan 2019 13:46:11 -0800 (PST) Subject: Re: What is this GetDynamicUsers about? To: Dominick Grift , Russell Coker Cc: "selinux-refpolicy@vger.kernel.org" References: <2151367.RAjrkxNSSX@liv> <871s5825jy.fsf@gmail.com> <84957EBD-2306-46DF-9089-1637D1438CFA@coker.com.au> <87won0zuky.fsf@gmail.com> From: Chris PeBenito Message-ID: <5a1aa9d2-39dc-6a16-cd57-963b974df44b@ieee.org> Date: Sun, 20 Jan 2019 16:29:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <87won0zuky.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org On 1/19/19 7:43 AM, Dominick Grift wrote: > Russell Coker writes: > >> Thanks for that! Should we change auth_use_nsswitch()? > > Yes but theres another thread on this maillist that is used to discus > this matter, as adding support for this (and support for other systemd > nss modules (like myhostname and mymachines etc) is very intrusive as it > gives nss users access to dbus. So i think refpolicy is still weighing > its options here. It still requires further thought, but it might end up being more tunables and/or interfaces. I want to make sure it's possible to split out the network access and dbus access (thinking ahead to the above nss modules). >> On 19 January 2019 11:30:25 pm AEDT, Dominick Grift wrote: >>> Russell Coker writes: >>> >>> It is kind of like a mcstrans thingy except this is baked into glibc >>> nss >>> via the nss-systemd module. it translates dymamic user id's to >>> something >>> that is human readable. >>> >>> dynamic users are temporary users identities that can be created by >>> systemd >>> on the fly for your service. Theres only a limeted range of system user >>> identities (<1000) available and this allows one to just create an >>> identity on the >>> fly for a service via the systemd service unit. >>> >>> This is a pretty intrusive feature. Consider the following: >>> >>> you have a service with a dynamicuser (say "myservice") this service >>> creates files for example a log file in /var/log. When the service >>> exits >>> the uid no longer exists and so you have a file in /var/log with a >>> userid that does not exist eny longer. >>> >>> This is why you see the "private" dirs in /var/lib, /var/cache and >>> /var/log. the services see the private dirs are the root for these >>> respective dirs. (its using a symlink: example: /var/lib -> >>> /var/lib/private) So the files that might end up with orphaned >>> identities are atleast kept separate on the filesystem. >>> >>> So myservice maintains the log file in /var/log/private instead of >>> /var/log "transparently" (this all needs to be configured though in the >>> service unit) >>> >>> There can also be a file in /etc/systemd called something like >>> "dont-synthesize-nobody" users of nss-systemd will look for that file >>> (just a get attributes) So you might see these processes atleast >>> traverse /etc/systemd, looking to see if the flag-file exists) >>> >>> So yes fully implementing support for dynamic users is far-reaching (i >>> did this in dssp2-standard) >>> >>> You can play with this feature with `systemd-run --system -p ... [...] >>> -t` >>> To see how it behaves >>> >>> But anyway back to your GetDynamicUsers question: users of >>> auth_use_nsswitch() (nss-systemd) need to potentially be able to >>> resolve these dynamic >>> user id's , for example if they read state on a system with processes >>> that are associated with dynamic uids or if they need to stat files >>> associated with dynamic uids. >>> >>> I hope this helps >>> >>>> # msgtype=method_call interface=org.freedesktop.systemd1.Manager >>>> member=GetDynamicUsers dest=org.freedesktop.systemd1 >>>> init_dbus_chat(postfix_showq_t) >>>> dbus_system_bus_client(postfix_showq_t) >>>> >>>> # msgtype=method_call interface=org.freedesktop.systemd1.Manager >>>> member=GetDynamicUsers dest=org.freedesktop.systemd1 >>>> init_dbus_chat(dictd_t) >>>> >>>> The above is from my policy that hasn't yet seemed good enough for my >>> Debian >>>> tree. What is this GetDynamicUsers about and why do programs like >>> dictd >>>> (dictionary server) and postfix showq need it? > -- Chris PeBenito