Re: aname_to_locaname vs gssapi svc/host.domain.org@REALM

On Wed, Oct 26, 2011 at 2:53 AM,  <[email protected]> wrote:
> I'd like to thank you Nico for identifying the core issue.

Well, I did antagonize Harry a bit, so, maybe it's a wash.  I wish I'd
seen Harry's point earlier, though I still think Harry should just
avoid the issue altogether.

Also, regarding Apache...  Yes, Apache has a legitimate reason for
being a daemon that is also an NFS (or AFS, or...) client.  However,
Apache is effectively a proxy for its clients.  Therefore Apache
either needs to be considered part of the system that the clients are
accessing and therefore, like the NFS software, fully privileged to
access all of that system, OR it needs delegated credentials (possibly
-preferably!- constrained) with which to impersonate the clients to
the NFS backend.

The edge service (Apache) as proxy or core service issue comes up a
lot.  "Host-based user" naming is not an applicable solution to it.

So, I hold to the following:

 - for most system daemons there's no reason to ever touch NFS (or
AFS, ...) outside a diskless client case
 - for disklessness you should use iSCSI
 - for Apache you either need to give it credentials that have the
same access as the union of all of Apache's legitimate client users,
or you need to have it used credential delegation, preferably in the
form of constrained credential delegation (see S4U2Proxy)

This leaves you with a need for "host-based user naming" only for
applications that are a) not in the same category as Apached, b)
automated and not directly related to any one user, and which c) need
isolation/partitioning across groups of hosts.  This is a *legitimate*
use-case.

Minimizing the number of legit use cases for host-based user naming is
important because minimizing the impact on the namespaces you have to
manage is important.  Namespace explosion is not fun, much less cheap.

(Harry's focus on things like nslcd is, I think, what kept me from
addressing this legitimate need for host-based user naming.  I just
couldn't get past what I think is a bad example.  Sorry.)

> On Tue, Oct 25, 2011 at 09:32:07PM -0500, Nico Williams wrote:
>> The next simplest is to use "host-based usernames".  MIT krb5 makes it
>> easy to map these to whatever server-side usernames you want, but
>> since that means having either distinct usernames on the server for
>> each host instance of the same client-side username, that gets
>> complicated pretty quickly.
>
> It is not more complicated than the access control granularity which
> you need.

The size of the namespace to be managed has something to do with the
cost of managing it.

> <offtopic = NFS>
> Do not assign distinct user names after the hosts they are
> running on but rather after the access rights they are supposed
> to have. I.e. not account_f_q_d_n but account_hostclass which means
> actually account_accessclass  (avoiding '/' makes it actually
> implementable despite all weird hardcoded assumptions about account
> names in different places).

Naming users after the access they are supposed to have doesn't help
in a dynamic world because that level of access will change over time.
 Any way you dice it the access these accounts are supposed to have
will be related to sets of subjects (in this case: sets of related
client hosts) and/or resources (which, in Harry's example are
intimately tied to the sets of subjects), so you end up with at least
an explosion based on the number of distinct sets of subjects.

Now, if you have few such use cases and few such sets of related
subjects, then it's manageable.  If you let this get out of control
you end up with a namespace explosion.

> The number of accounts=principals to maintain can become
> O(<suchaccounts>x<hosts>) but only in an extreme case. It is always
> O(<suchaccounts>x<accessclasses>) which probably is much less.

Yes, but that's bad enough IMO because it won't scale to a large
enough deployment.

> So it does not have to be complicated and does not need any
> extra support from the OSs, NFS or Kerberos.

It requires a suitable aname2lname facility, which Heimdal lacks.

Also, you really want to avoid collisions with host-based service
names.  Methinks we should standardize a host-based user naming
convention for that reason.

> Such an access control is more general than the suggested (hypothetical)
> file labels per client host which you mention later (this allows e.g. to
> move two accounts' instances together to the same host but still keep
> their access rights separated).

First off, labeled security is not hypothetical.  What is hypothetical
is the required protocol extensions and server-side features in NFS,
but these are already in progress (you can see this by looking at the
IETF NFSv4 WG mailing list traffic over the past year on the subject
of labeled security).

Windows 8 has a variant on labeled security called claims-based access
control (CBAC) that is not hypothetical either.

> That said, a deeper redesign would certainly give Harry an even simpler
> and more maintainable system than keeping those host-related acls which
> were conditioned by the old NFS3. Getting rid of NFS-conditioned
> assumptions is not easy - hard in the existing setups, even harder
> in the minds of people (not meaning anyone here).
> :(

The deeper redesign that is coming is labeled security.  I don't know
what else could replace it while also avoiding the namespace explosion
discussed above and earlier.

Nico
--