On Tue, Oct 04, 2011 at 04:57:38PM -0500, Harry Coin wrote:
> There is clarity as principals when people have their account and their
> account/admin principals. Hoping to extend that clarity to the root /
If you look a bit deeper, there is no "clarity". There are some practices,
traditions and things which the API suggests and/or KDC implementation
allows.
Identities (among others, used by applications) need the ability to be
allocated in the principal name space.
Usage of name spaces is a more general topic than Kerberos and
actually Kerberos remains quite poorly explained and hence
controversially^WI would say improperly used in that respect.
Fortunately Kerberos offers a hierarchical principal name
space. Unfortunately it is implemented in an obscure way.
IIRC you can even have a principal with '/' inside which is not a
delimiter...
More obscurity is added by the fact that the traditional examples
reflect simple (I would say oversimplified) cases of name allocation.
As a result, confusion about a presense of a "standard" structure
of the principal name space is widely spread and very deep I guess.
(How many people are e.g. aware of the fact that there are more than two
components available for use in a Kerberos principal name?)
Note that the (quite primitive) acls on KDC which are usually being
used for simple */admin-patterned KDC-related-privilege assignment have
nothing to do with the way other applications (services) might allocate
and interpret the name space. KDC is just one of the Kerberos-aware
applications. As soon as you have got two more, it is in minority.
As the matter of fact, the principal name space is used ad-hoc, near to
becoming insecure as the deployers do not understand the semantics of
assigning a principal name.
It is illustrated by the "pragmatic" behaviour of gssd which you mention.
Its use of "mostly anything which ends with /<fqdn>" suggests
that the semantics of its principal is "the local super user/kernel" whatever
the name would be and it tries hard to guess what the local realm
administrator would call this. Note also that this can be totally incompatible
with the use of .../fqdn by other applications on the actual computer.
It does not matter what the name is and actually gssd _should_ take
the name of the principal to be used as the mandatory parameter, then
there would be much less confusion and more security.
It would become more evident that the name
1. _is_ arbitrary
2. _has_ to be decided for the actual setup/realm and application,
3. carefully to _avoid_ reuse of the principal for
4. _incompatible_ purposes.
Note the reuse (which is dangerous) and the (in)compatibility
between different uses of the same principal which only can be decided
in the local, actual context.
> service <-> principal naming best practices.
> Is there consensus that a common understanding has merit for
> <whatnot>/<fqdn> means?
See above. Name the principals what you like as long as you prevent
name collisions between identities in your realm. Do not forget that
a principal name only makes sence given both the application and the
actual realm. host/admin@FOO does not imply the same use as host/admin@BAR
while there is nothing wrong with these names - _if_ the corresponding
applications (say, the kdc in FOO and the site dhcp manager in BAR)
are the only ones using the corresponding principals.
Planning name space allocation is otherwise an important work. It is easy
to make mistakes which are hard to fix later. The related best practices
are though not Kerberos-specific. One general suggestion: do not mix
"reserved" vs "free" strings in the same component of a name, to avoid
the need of extra filtering (host/* and *[/admin] being an example of
a bad structure, user/*[/admin] and host/* coexist much better).
(Oh yeah, the (bad) traditions do not make it easy to let pam
automatically add, say, "user/" in front of the user name. We had to
hack pam_krb5 to allow for affixes... It is just another not so good
tradition that the user principal is expected to coincide with the OS
user name. There _always_ is a mapping (even if it often is "no change")
as the_two_name_spaces_are_different. An affix is a quite powerful form
of mapping, much more general than only allowing equality. Why isn't
it there in all pam_krb5? Empty affix is trivial to use too...)
Hope this makes sense in your eyes.
Best regards,
Rune
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.