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

[Simo Sorce]

On Thu, 2014-03-27 at 18:18 -0400, 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.

Also let me add that NSCD wouldn't be a good solution anyway.
NSCD is dumb (reason why we have our own similar mmap cache in nss_sss
instead of using NSCD), and has no idea of the status of the network and
will expire all caches after a while whether you regain access to the
network or not, plus IIRC enumeration is never handled via NSCD so some
operations will still fail hard.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York