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

On 10/22/2011 10:38 AM, [email protected] wrote:
> Hello Harry,
>
> On Fri, Oct 21, 2011 at 07:34:58PM -0500, Harry Coin wrote:
>> 1. Absent these patches: NFS + kerberos authentication, integrity or
>>     encryption security (sec=krb5 krb5i krb5p) only is available for
>>     those accounts with kerberos principals having the form xxx@REALM
>>     <mailto:xxx@REALM>  --with no /.
> I understand that you want to make the principal-to-unix-account-name
> mapping more flexible for the sake of NFSv4's constrained implementation
> (access rights are connected to the local uid on the server so the server
> must map a principal name to a local unix account).
>
> Such a mapping arrangement might make sense (on an NFSv4 server) but
> at least libnfsidmap-0.24 does not seem to do any mapping via Kerberos
> libraries so your patch would be bypassed (which for me seems reasonable,
> Kerberos business is between processes, normally of different hosts,
> not of Unix local identifiers).
>
> Do your NFS servers behave differently and call aname_to_lname()?

Yes.  Through a long chain winding in and out of the kernel eventually 
calling a userland daemon gssd.
If you take the time to focus on how and when the procedure with I bug I 
fixed gets called, you will comprehend.

http://www.freebsd.org/cgi/query-pr.cgi?pr=161854

and
http://svnweb.freebsd.org/base/head/kerberos5/lib/libgssapi_krb5/pname_to_uid.c?revision=181344&view=markup



>
> Note that there is a general and straightforward workaround - letting a
> daemon use different Kerberos credentials for its own service and for
> accessing the NFS service. This should be easy to setup (_is_ easy on
> Linux, did not test on other client platforms).

Ah if only.  You'll note the kernel 'taint' process prevents drop-root 
services from doing anything of the sort.  All credentials must be read 
through whatever is in /etc/krb5.conf.   For both security and 
maintainability the goal is to have only one principal per keytab file 
and have that keytab file be only owner readable and owned by the 
drop-root user.


>
> Services other than NFS and login do not need mapping to host-local names
> anyway.

Except ldap, nscld, local root which must use the local passwd.  (Bad 
practice to have to maintaina password on kerberos for when the net is 
up and another local one for when it isn't.)   Oh, and anything 
whatsoever that uses gssapi that happens to be written for local 
production purposes in ongoing applications not generally available as 
ports or packages being of no general interest -- but the reason the 
locals care about any of this whatsoever.


>> For example if the file
>>
>> /etc/k5login.d/ldap
>>
>> had the content
>>
>> ldap/*[email protected]<mailto:ldap/*[email protected]>
>>
>> then any principal using the GSSAPI format ldap/anyboxname.domain.com
>> would be associated with the local user ldap.Calls to kuserok asking
>> whether principal ldap/foo.domain.com matched ldap would return ok.Calls
>> asking aname_to_lname what local user should be associated with
>> ldap/[email protected]
>> would get ldap.
> Would you explain for me, when and why your example above or a similar
> setup would be needed (you seem to be using this and I want to
> understand your case). The above hardly helps for Kerberized NFSv4 (?).

I've tried in the past, I don't know how to say it differently.     Here 
goes:   Existing applications use local accounts.  Many existing 
applications use network services.  These have plenty enough to be 
getting along with every day without having to worry about the little 
dance between user names and uid's.  And it all works.   Enter 
kerberos.    Kerberos is the change, it offers security, which is 
valueless if it breaks what the security is looking to secure in the 
first place.  Now each local user account that has some identity that 
goes beyond one box needs a kerberos principal.  We have to add this 
without breaking what we've already built beyond a little 
installation/shakedown.  That means we cannot be in the business of 
having to patch and locally maintain lots of packages in order to gain 
this benefit.    We're using this in daily operations, it isn't an 
engineering lab where we can delight in making changes owing to their 
inner beauty if they generate unmanageable regressions.   Applications 
like ldap, nslcd, nfs, anything that uses sasl -> anything that uses 
gssapi with kerberos underneath it, wants that principal to be in the 
form <account>/box.domain.org@REALM.   That's the one that's going to be 
mapped to <account> in the local passwd database only if the account is 
of the sort that must work if the box's network connection is down.

  I understand plenty of folk take issue with the foregoing.  I have 
packaged all their perfectly intensively thought through structures and 
proposals here on this list and presented them to the system I have 
right in front of my nose.  Strangely it is unimpressed and cares not at 
all about being in a state of disagreement with the great minds of 
heimdal-- it just refuses to work.  Modify configuration files all month 
and still, no joy.   Being that if it isn't happy, I'm out of a job, 
you'll forgive me if I defer to its needs.    I do not have the luxury 
of focusing on one application and making it work, I have to make them 
all work and they all have to work together on the same box at the same 
time.   Moreover, I cannot be in the business of writing and patching 
lots of daemons and services and packages and sweating about whether the 
next update will break them.  Certainly for so many applications I do 
not want to be forced to download sources, apply local patches, 
recompile and distribute the local version across the realm.    I have 
to pick the one thing which if addressed will allow all the others to be 
used without local changes and recompilations of any sort.   And that in 
this instance is heimdal.  Down at the roots of it all.

So, I wrote the changes and patches.  I added a cache so kuserok and 
aname_to_lname is fast.  I created one structure that anyone can 
understand in /etc/k5login.d  in one place manages the maps between 
users to principals and the reverse principals to users.   So it is 
maintainable.  I gave admins the ability to prevent root authority 
daemons and system service daemons from using what some random user 
decides to put in their local .k5login file.  I crafted a means so that 
the library can function properly without waiting for all the various os 
kernel guys to solve what 'taint' means.  And I did it in a way that 
doesn't alter current behavior absent admin change asking for the new 
abilities.


> The only other services that I can think about, which concern mapping
> to local uids, are login and friends - i.e. initiating processes on a host.
> Why would you need to login to a host as "ldap"? How the entity (a human?
> another host?) logging in would know the "ldap/the.box" password if it is
> in the keytab on the target box and hopefully nowhere else outside the KDC?
>
> If all you need is a login to a host as "root" (which is often
> discouraged for good reasons but can be desirable nevertheless), then
> a fully transparent approach would be to set up pam_krb5 so that
> on host box1.doma.in it checks passwords of either "account" or
> "account"/"box1.doma.in" principals. You have Russ's module which
> implements this.
>
> (Also, why do you have to use "root/box1.doma.in" and nothing else?
> "root-box1" account in the local passwd, either with uid 0 or with sudo
> rights, would be sufficient and a corresponding Kerberos principal would
> have the same name.)

Because only that will do the right thing if I care about anything that 
employs gssapi-- and that I need to not break all the work that quite 
happly functioned pre-kerberos.     And, because I do not want to 
maintain passwords people have to know about in more than one place I 
will only create a random password keytab structure for root/box... the 
'password' for local root will be only in the local box's passwd 
database.   That because the local box has got to do the right thing if 
it isn't connected to the network.


>
> In other words, despite having read your notices for the patches
> I am still confused and ask for your indulgence and more explanations.
> Better look stupid once than remain forever ;)
>
> [The purpose of the keytab name expansion seems otherwise clear (work
> around a harmful paranoia check in the library itself). I understand
> why you are doing this, even if I'd prefer a different approach.]
>
> Regards,
> Rune
>
>

Rune,  I appreciate that you care and you have a vision for all this 
that I do intuit has long term merit.     However, I am not able to 
deploy your thoughts because when I try the systems in front of me 
fail.   I suggest you try this:   Get two boxes and a hub that are 
otherwise going to be thrown away.   Load freebsd stable on one.  Load 
whatever linux distro you prefer on the other.    Do an nfs share, set 
up ldap/slapd on the freebsd box and run nslcd and make it the kdc.    
Now, on the linux box, set it up to be a client of the freebsd box.   
Mount an nfs share.  Set up pam to use kerberos and get nslcd and 
nsswitch and so forth configured properly.  Create some realm principals 
that don't have local accounts in the passwd database but only exist via 
ldap.

So, now you can do an ls -l on either system and see the proper owners 
of files created by anyone.

Now, here we go:   Change the nfs share to require kerberos.  No 
auth_sys for any part whatsoever.   Change ldap so it can't do anonymous 
binds and must rely on sasl->gssapi->kerberos.    Make it so ldapwhoami 
fails, and the only way it can work is ldapwhoami -Z

Then, write back here with how you've formatted your principals, what is 
in your configuration files.   Only then will I be able to see what it 
is you are trying to accomplish.