F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/27/2014 06:18 PM, Simo Sorce wrote:
> On Thu, 2014-03-27 at 22:59 +0100, Lennart Poettering wrote:
>> On Wed, 26.03.14 13:43, Stephen Gallagher (sgallagh at redhat.com)
>> wrote:
>> 
>>>> Note that PrivateNetwork=yes should not be used for:
>>>> 
>>>> 1. Services that actually require network access (with the 
>>>> exception of daemons only needing socket activation) 2.
>>>> Services which may be used to execute arbitrary user or
>>>> administrator supplied programs. (see above) 3. Services
>>>> which might need to resolve non-system user and group names.
>>>> Since on some setups resolving non-system users might require
>>>> network access to an LDAP or NIS server, enabling this option
>>>> on might break resolving of these user names. Note however
>>>> that system users/groups are always resolvable even without
>>>> network access. Hence it is safe to enable this option for
>>>> daemons which just need to resolve their own system user or
>>>> group name.
>>> 
>>> This may not be a safe statement to make. I personally know of
>>> a great many deployments where admins have removed the local
>>> accounts for
>> 
>> Well, this assumption is built into a lot of software we do, for
>> example all across device management, tmpfiles and suchlike.
>> System users must be resolvable without network, we cannot delay
>> bootup for these components, just because the network isn't up
>> yet...
>> 
>> It's OK to if normal users are only resolvable with the network 
>> round. And it's OK to sync system user IDs across the network,
>> but they must be resolvable at any time -- they are integral part
>> of the core OS after all.
>> 
>> People can use a caching daemon (like sssd?) if they like, to
>> make sure the system users stay in syn across the network, but
>> removing them from /etc/passwed entirely is nothing we ever
>> supported or should support.
>> 
>> I mean, it's even OK if people "hack" things that way, if they
>> want to shoot themselves in the foot, and know what they do. But
>> that really shouldn't stop us from deploying PrivateNetwork=yes,
>> since there is a very easy way out for them: just enable nscd.
>> With nscd enabled the NSS calls will go via the nscd AF_UNIX
>> socket in the fs (which is connectable, regardless of
>> PrivateNetwork=yes), and then the actual query is made from nscd.
>> Or actually, to top that, people who have setups like that, and
>> store their user databases on the network, for example in LDAP,
>> are the ones nscd has been written for in the first place, and
>> hence there's really very little changing for them.
>> 
>> But anyway, it's a hack to allow system users to be removed from 
>> /etc/passwd. It's already broken if you want to support that, you
>> have to file bugs to udev, tmpfiles and so on. And yuck, I don't
>> even see how that could ever work...
>> 
>>> We'd need to think very hard about whether any service should
>>> have this turned on by default. If we *do* enable it by
>>> default, we should also carefully document how to turn it off
>>> for those services if they rely on centrally-managed accounts.
>> 
>> I think we can cover this one line: "if you do something like
>> that, don't. if you insist, use nscd". And that should be
>> enough.
> 
> It is doable without issues and withut needing nscd with sssd, so I
> do not think we need to CYA with this line at all.


Yes, see elsewhere in this thread. I was forgetting that the remote
capability doesn't happen in-process, it happens as part of the SSSD
daemon (which obviously wouldn't use PrivateNetwork=yes). It's more of
a risk with the old nss_ldap, but I don't think we even ship that
anymore (replaced with nss-pam-ldapd)

As long as this isn't in any way interfering with UNIX sockets (which
it must not be, if nscd would work), then I see no issue here with SSSD.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM1YTkACgkQeiVVYja6o6NlMQCgqPy86NQ175UsOzQ6Og3ODbbe
YOMAoIBO0ZhbueWMlTdwFKYT2IhhNt/s
=GyTT
-----END PGP SIGNATURE-----