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 X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 5D714C61CE4 for ; Sat, 19 Jan 2019 12:43:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2A8712086A for ; Sat, 19 Jan 2019 12:43:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kQBn0yrk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728022AbfASMn3 (ORCPT ); Sat, 19 Jan 2019 07:43:29 -0500 Received: from mail-ed1-f68.google.com ([209.85.208.68]:43393 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728021AbfASMn2 (ORCPT ); Sat, 19 Jan 2019 07:43:28 -0500 Received: by mail-ed1-f68.google.com with SMTP id f9so13212221eds.10 for ; Sat, 19 Jan 2019 04:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=vGsJZArpTwbrVvNZsSJlJUjus/1b9dc+5YHB07kTqLU=; b=kQBn0yrkKqo7Zd3ChdqBy+8HAo7nKAa/E3NKpcxUz0TApKLYYusDcPCP7UB1xcpKoX oYBDsELJTxWJBcQnHC1CEG2iKMFChiCzmbuXkqEMmXofXgSsl1odhjI/p/jqLeZGagN2 iXhM+t0m/8gPO99CUDAz9ukXJQ0uovsymAXblAjVhDXzm/YffoRJ9DKg/613aITywIne 5YC6zje3WAaIaGztPes5blUSj6iLVl7yVGi4BrWHT6IV2bcJSmjVhfVaicC6rFBwCC47 Nn88JXNE62TNC8LnNx3j6Pc7Zbl8U7xZCCUpZjbjooqrzAmZIIm/4wGk5GddEjfqLveB XfNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=vGsJZArpTwbrVvNZsSJlJUjus/1b9dc+5YHB07kTqLU=; b=l0mSTZYh9+vBI9qACooJ2SBxUNwo2pVI3M0SUVEX3VQM/LjAsI6y2S0sXpvSBbi3NS q7fTovXYrpxgJLKmgAEQmzbqsZnOInzyLPkyBKd9dFoIqU+qD4TgrQ1jnM9Hfjc89CiO lInoSIQ32FUGkTcnf5p3kUR1npzuYLbZJDeVCICB2GO8tt0XzDrKOMZWzCedvODjglF2 GCN9FvBFFS8LZWOrscqtqvI/wR5qJt8Cydeb7L7v/vcio6okN3iuSilEvk8ZCBEgDt1G yRJTHpnrSznuc08DegrqBGRWvdZuwyd5t8wybbYrITkLMOJ1HlVkoHBjgrIUBm3vSyMZ aHgg== X-Gm-Message-State: AJcUukdkv3da42CYG2iVqQwSxKkA33wngOv2hjhxP2p+IhEqUZErekJl +U75v933HbWWxZbu1Peysf7b4+Ou X-Google-Smtp-Source: ALg8bN5XTxDU/2TistX5w7oqhTHrrRkXdFQkN5R40pFjwPm1+TXndcwgo9zcf+76KWB+eNL8FlcGMg== X-Received: by 2002:a50:903c:: with SMTP id b57mr20107061eda.161.1547901806603; Sat, 19 Jan 2019 04:43:26 -0800 (PST) Received: from brutus ([2001:985:d55d::438]) by smtp.gmail.com with ESMTPSA id u33sm7746278edm.88.2019.01.19.04.43.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 19 Jan 2019 04:43:25 -0800 (PST) From: Dominick Grift To: Russell Coker Cc: "selinux-refpolicy\@vger.kernel.org" Subject: Re: What is this GetDynamicUsers about? References: <2151367.RAjrkxNSSX@liv> <871s5825jy.fsf@gmail.com> <84957EBD-2306-46DF-9089-1637D1438CFA@coker.com.au> Date: Sat, 19 Jan 2019 13:43:25 +0100 In-Reply-To: <84957EBD-2306-46DF-9089-1637D1438CFA@coker.com.au> (Russell Coker's message of "Sat, 19 Jan 2019 23:39:24 +1100") Message-ID: <87won0zuky.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org 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. > > 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? -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift