Re: nfs client 'nobody no matter what' clarification was Re: k5userok .c / doc mismatch

On 10/14/2011 5:46 PM, Love Hörnquist Åstrand wrote:
>> Nico, thanks.   Freebsd has integrated heimdal.  MIT's kerberos has advanced capabilities in the areas I need to make my current project functional right now today,  but I don't see a documented way to specify it instead of heimdal.   I'd be grateful to anyone who could point me to a single option somewhere that lets me 'recompile the freebsd kernel and userland world' with MIT's version.
>>
>> I urge the heimdal  folk to recognize that there exists a category of realm usage which is 'more tightly controlled than usual' shall we say, where users with realm-wide single-sign on needs are very few and generally administrative in nature.   On the other hand,  I have plently of  userX/fqdn principals in the way gssapi likes to see them, but there is no meaning for a principal userX@REALM.
>>
>> So, until you folks clarify the foggy future into code, I'm either going to have to write it myself only if that seems less bothersome than switching freebsd to MIT's kerberos.
> Harry, can you describe what your use cases and what your expectation are.
>
> Love
>
>

Love, thanks.  I'll just summarize the path that led me here.

# processors / # staff --> big and getting bigger.     Very few   
name@realm (nearly all admin staff), lots of <various 
services>/[email protected].  No 'root@REALM' or even 
'service@realm'.

We recognize the day is coming that previously physically secured 'air 
gap' internal networks cannot be trusted to be free of mostly nuisance 
or 'random temporarily connected users without ill intent'.  Anyhow, 
whether by someone with a laptop that also has wifi or 4g, or a shared 
bridge on a cellphone with wifi, who knows, we know even our internal 
wired nets are often going to be no more secure on the inside of the 
internet firewalls than they are on the outside.    No special fear of 
intentional misdoers or thieves, traffic isn't financial.   Getting 
weary of Chinese based robots probing all the time via whatever someone 
is carrying in their pocket that gained access to some 'temporarily 
connected' wifi or even hard wire "just for a few hours for special 
event thus and so".  So, people's intent about doing the right thing 
isn't going to be enough.

The processors run the gamut of osen, mostly linux distros, some 
freebsd, an occasional redmond or cupertino box, now some android.

So, nfs has to move to krb5i and 5p.  ZFS is the flavor of the week, and 
that means freebsd, which means heimdal if I can manage it.  Ldap needs 
no anonymous binds & ssl.  So, hello sasl+gssapi, and the defacto 
requirement that local daemon account X have principal name 
x/[email protected].  It also means as few daemons running as 
root or equivalent group memberships as possible.

Now, these daemons are inter-related nfs clients  that update files on 
all manner of file services and servers.   The whole local world 
understands and requires that when  daemon X writes a file, no matter 
the server, the file's owner is daemon X  and NOT daemon 
X/[email protected] ---- any client authenticated as daemon 
x/<fqdn>@REALM (and with packets sourced from that ip) ought to be 
capable of acting as the owner of that file.   For other realms I 
wouldn't dream of such a thing.  But for this one it is essential.

Moving to secure all that can't impose on administrators the requirement 
that upon adding a new box and a raft of new principals for that box 
means also updating  .k5logins all over the place, or the equivalent of 
updating .k5logins:  making new groups/acls for each daemon and causing 
systems maintain and update the boxes as they come and go.  The fact we 
create  principal "daemon x/box.domain" is authentication enough that we 
mean for it to have access as a network client to all daemon X had 
running on that box before krb5p/5i needed to happen on the wire.

Moreover-- specifically creating principal x/box1.domain is NOT giving 
x/box1 principal the right to ksu, ssh, telnet or otherwise log in at 
all as x/box2 on box2 contrary to this nasty side effect of requiring 
.k5login permissions.  I will NOT be putting anything about other boxes 
in any configuration files on any given box.  I don't want ksu to be 
even on the radar.   As for pam, all the uids involved in these daemons 
are under the limit we allow for kerberos-pam to function-- no logins.   
Startup script launching only.

So the heimdal tensions began when I needed to support openldap's slapd 
server's good intentions of dropping root to a uid !=0 account.  That 
ran afoul of what different osen deem 'tainted' means,  blocking krb5's 
access to environment based keytabs.   A good discussion ensued 
involving many applications of 'should' and 'ought'.   The end result I 
knew I needed was one key per keytab with permission 0400 owned by the 
specific local daemon account needing it.   Read upstream-- the here and 
now answer I had to implement myslef:  a UIDF keytab 'filetype' that 
tried /etc/keytabs/krb5.#effectiveuid#.keytab before defaulting to 
krb5.keytab.     Those that think of that as an ugly hack or security 
hole I think are entitled to that view, but as I have to make actual 
progress and no other answer was forthcoming that had a prayer of 
working across osen and their various concepts of environment 
sanitation, 'taint' and effective uids:   it enabled me to move ahead 
still having drop-root ldap servers and clients with processor specific 
1-key keytabs.

So-- fully sasl authorized no anonymous bind ldap services are running 
using ssl.   Similar battles for gssd, nslcd discarding the libraries.  
Battle on for krb5i / krb5p--  and why did -maproot=root:wheel fail on 
all the daemons?   Turns out they had the bad grace to run afoul of 
contra-documentation heimdal principal name orthodoxy.   I do know much 
more about nfs and mountd , nfs3 and nfs4 inner workings that I ever 
wanted to know drilling down to the krb5 library code as the culprit.   
Love updated the documentation correctly describing that there never was 
any hope as the code was written.

Daemons that had full access to what instances of the same daemon 
running on other boxes wrote on nfs shares now plainly are barred from 
using kerberos krb5 via heimdal.

And, here we are.    I hope other options the wise here will reveal to 
me.  As I see it I'm either going to find an easy way to switch to MIT 
that has all the equipment already in it on freebsd (I think this 
unlikely), or:

1. change kuserok so in the event it can't find a readable .k5login to 
look in /etc/k5login.d/username and if reading from there compare 
principals not using principal_compare but instead the pattern matching 
principal_match.  This is for cases when testing a specific principal 
against a specific pre-known user.

2. change aname_to_localname to read through the files in /etc/k5login.d 
in no specific order except not processing principals after a line 
beginning with ##<some tag I haven't thought of yet>##.  The first 
positive match of aname to a principal in that soup returns the user 
name given in as the filename in /etc/k5login.d

Those two changes I think will make all well for nfs3 and 4 in my 'few 
single sign ons, lots of boxes lots of inter-operating nfs 
writing/reading daemon/services' world.  Then I'll need to port it over 
to the other osen and take on the burden of patching and updating the 
source trees across updates, cest la vie.

Love, I hope that answer is what you were looking for.

Harry Coin