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

Hi Love,

On Wed, Oct 12, 2011 at 01:23:53PM +0000, Love Hörnquist Åstrand wrote:
> > If an NFS server maps "user/root" to "root" and then presumably to uid
> > 0, this may have far reaching consequences if this is hardwired in the
> > server code, depending on the actual setup of the NFS server and on the
> > principal management policies at the corresponding KDC.
> 
> Yes, using unix style authentication is bad in NFS, however, in kerberos, if you don't want a foo/root to be mapped to root, don't add foo/root to the ACL.

This is what I am trying to say too, use ACLs instead of relying on a
certain spelling of a class of names.

> > It will have zero impact _if_ such principals are only being created
> > for persons allowed to access the exported resources as the server's
> > superuser.
> 
> I don't understand this statement wrt to krb5_aname_to_locaname and root.

I did not ever mean to talk about krb5_aname_to_locaname(), but very
generally about consequences of using principal names for authorization
purposes. The algorithm or the implementation do not matter.

> > Any other use of such principal name is thus effectively
> > disallowed (for a safe and reliable setup).
> 
> Its denied by default disallowed by krb5_aname_to_locaname()

Good, but it looks like we are talking about different things.

> > IOW use of a certain form of a principal name by a certain service
> > reserves this class of names for the service. That's why I am convinced
> > that conscious allocation and management of principal name space is
> > crucial.
> 
> I totally disagree. This is how we get into the problem what users can't get keytab's because that will make everything insecure.

What you describe is a consequence of improper use of the principal name space.
So it looks like we agree.

> > To make it easier, it might be better to avoid hardwiring any
> > meaning into the names.
> 
> It will be made easier when services adopt ACL management system.

Sure.
Given of course that ACL do not use/suggest "wildcard" notations like,
say, KDC does. Otherwise the following fully aplies:

> > It is both
> > 1. an allocation of a part of principal namespace for a certain service (!)
> > and also
> > 2. an implementation of a certain policy which _must_ be reflected by
> >   management rules for such principals.

> Its well spread enough that Russ implemented something like it for his pam_krb5
> 
> 	http://www.eyrie.org/~eagle/software/pam-krb5/pam-krb5.html

Yes, it is an example of reserving the semantics of a part of namespace
for a certain service (host-local authorization aka login).

Russ' module is good (the mapping principals->semantics is configurable) but that page
does not ever warn "if you made the choice like 'alt_auth_map=%s/root' then
DO NOT use principals of that form */root for anything else UNLESS you know that
the set of identities to be allowed "THIS" and "THAT" will ALWAYS coincide'

The things above about THIS, THAT and ALWAYS is crucial for security but hardly
anyone thinks about it while blindly following the proposed example.

One thing which is easily missed is that the pam.d/xxxx is host-specific but the name space
reservation is realm-specific, i.e. much wider.

> And if you care for documentation
> 
> 	man /usr/heimdal/share/man/man3/krb5_aname_to_localname.3 

I would have to login to your computer to be able to use that path :)
(A path on AFS or Coda would otherwise work...)

Well, as I happen to have a copy of that, somewhere else, I read the
page. It does not say in which way it maps the principal to a "local
name". It looks uncertain what it actually does and how to rely on it
(Use The Source Luke?). Anyway, it somehow yields a "local name" which
suits for login but this is not applicable to non-login kind of services,
like for instance NFS or, say, Print.

This is what I can say of this man page... Nice that it exists but it
hardly helps to understand _whether_, _why_ and _when_ the function
should be used.

I appreciate Kerberos and particularly Heimdal, so don't misunderstand
my rants. I want Kerberos to be usable and used widely, safely and
efficiently. The confusions around the concepts hinder all of this,
and there are non-Kerberos-specific ones too, like this - the semantics
and use of different kinds of names.

Thanks for your work on Heimdal Love.

Regards,
Rune