[OpenAFS-devel] aklog on MacOS X was Re: Service Ticket Questions

[Henry B. Hotz]

Just to be clear my desire is that OpenAFS provide a documented  
interface (like Heimdal kafs) that can be used by different people on  
different OS's to provide whatever hooks are appropriate to that OS.   
E.g, PAM on Solaris.  We seem to be unclear as to the proper  
mechanism to use on MacOS, though the "KLL loginLogout" plugin  
appears to be the best one available.  Except as that plugin  
interface was provided by MIT I think this discussion belongs on  
OpenAFS now.

Is there any documentation that describes the relationship between  
Authorization Services and the AuthenticationAuthority field in  
Directory Services?

On Mar 18, 2006, at 10:28 AM, Alexandra Ellwood wrote:

> On Mar 18, 2006, at 4:34 AM, emoy at apple.com wrote:
>
>> On Mar 17, 2006, at 7:33 PM, Jeffrey Altman wrote:
>>
>>> I am cc'ing the openafs-devel at openafs.org mailing list because  
>>> this is
>>> really an OpenAFS discussion.  krbdev at mit.edu is meant to be a  
>>> mailing
>>> list focused on development of the MIT Kerberos reference
>>> implementation.
>>>
>>> The fundamental issue being discussed here is whether the  
>>> Kerberos.App
>>> display of the Kerberos Credential Cache contents can be used as an
>>> indication by end users that the AFS kernel module contains  
>>> tokens for
>>> that user.  Hank is claiming that presence of an "afs/ 
>>> cellname at REALM"
>>> service ticket in the credential cache is an indicator that there  
>>> are
>>> AFS tokens installed in the AFS kernel module.

With all respect to Jeffrey, I think it is "not Mac" to have one part  
of the system showing you something that's inconsistent with another  
part.  I think a "typical" user neither knows, nor wants to know the  
distinction between the Kerberos ccache and the kernel token store.   
Therefore we owe it to them to make the distinction go away.

Doing otherwise invites confusion, after all we're telling them we  
use Kerberos aren't we?

If you want to "fix" the problem by preventing the ccache from ever  
showing an afs service ticket, that's at least better than letting  
them be inconsistent.  However you have now created a need for yet  
another GUI to manage tokens.  I don't think this is a good trade- 
off.  I've used the Arla afslog GUI, and I hate it because it's too  
small a function to justify its own slot in the Dock, much less a  
whole GUI.

To clarify that last a bit more:  I think getting/destroying tokens  
is a normal user operation that happens all the time.  Configuring  
the AFS client is something that the user may never do at all (if he  
gets a preconfigured installer for example).  They don't belong in  
the same GUI.  OTOH getting/destroying Kerberos tickets probably  
happens as often (maybe exactly as often) as you muck with tokens.

>>> I believe that end users should be discouraged from checking the
>>> Kerberos credential cache to see if they have AFS tokens because  
>>> doing
>>> so is fundamentally flawed.  There are many reasons why tokens
>>> might be
>>> removed from the AFS kernel after their initial installation let  
>>> alone
>>> reasons why tokens might not be able to be stored in the first  
>>> place.
>>> Therefore, using the Kerberos credential cache as a replacement for
>>> the
>>> "tokens" command or a GUI token display will only make the lives of
>>> end
>>> users and those that support them more difficult.
>>>
>>> If there is a concern that the presence of the AFS service ticket  
>>> will
>>> be misinterpreted as meaning that tokens are present then perhaps  
>>> the
>>> thing to do is modify aklog and anything that derives from its code
>>> base
>>> to not use the default credential cache and instead use a local  
>>> memory
>>> cache.  We could make this the default behavior and allow the  
>>> default
>>> credential cache be used when "-d" is specified on the command  
>>> line to
>>> allow the presence of the service tickets to be used for debugging
>>> purposes.
>>
>> One other place that the credential cache and the AFS token get out
>> of sync is when trying to renew the TGT.  Renewal of the TGT and AFS
>> token is a whole subject on its own, but suffice it to say that
>> running "kinit -R" will renew the TGT, but remove the AFS service
>> ticket, while the AFS token remains unchanged.
>
> This is not an issue for the KLL loginLogout aklog plugin.  The KLL  
> loginLogout plugins run whenever new tickets are acquired,  
> including when renewal occurs.  All of this support works great  
> except when Kerberos tickets are acquired during console login.
>
> During console login the KLL is called by the Kerberos authplugin  
> which is loaded by authorizationhost.  In Tiger authorizationhost  
> runs as root or the securityagent user depending on whether  
> ",privileged" was specified in /etc/authorization.  The  
> authorizationhost is spawned by the SecurityAgent and is not part  
> of the chain of processes which will eventually be the user's login  
> session.  Unfortunately AFS only associates tokens with a user by  
> two mechanisms: magic entries in the user's group list or the  
> user's uid.  Since the KLL loginLogout plugins have neither the  
> user's uid or access to the user's group list, they cannot store  
> AFS tokens properly during login.
>
> Now I believe I asked Conrad Sauerwald to insert some code into the  
> Kerberos authplugin which tries to work around this issue.  If  
> ",privileged" is specified and the authorizationhost is running as  
> root, the plugin will try to call KLStoreNewInitialTicketCredentials 
> () with its effective uid temporarily set to the user's effective  
> uid.  Which means it might be possible to get the uid-based storage  
> working so long as ",privileged" is specified.  Folks should  
> definitely test this though because I haven't actually tried it  
> since before Tiger shipped.

This seems to be the minimum needed.  Ed Moy's comments suggest it  
can be done (thanks Ed).

We don't have a PAG replacement, which ought to solve this problem  
for us.  Let's not forget that, once we finish this bit, we need to  
look at whether it's possible to use kauth (Kernel Authorization) to  
re-implement PAGs.  MacOS 10.4 has not been a good release IMO.  At  
least in 10.3 we had everything except PAG-on-login working fairly  
well finally.

> Note that specifying ",privileged" isn't a big deal because the KLL  
> needs to run as root to read your /etc/krb5.keytab anyway.
>
>
> The best way to solve this is to have AFS use the Mac OS X Security  
> Session model for storing tokens so that it doesn't need to depend  
> on either the user's uid or their group list.  This is what  
> Kerberos uses for credentials and what most all of the keychain  
> stuff uses.  I'm not sure how much progress has been made, or if  
> the functionality necessary to make this work for a kernel module  
> is even present.  But really that's the right way to do it.
>
>
>>> While not part of the same topic, Derrick Brashear spent time this
>>> week
>>> attempting to prepare a KFM KLL plug-in for aklog that would work on
>>> Tiger and discovered that under Tiger we will not be able to provide
>>> such functionality.   We will work with Apple to try to make this
>>> happen
>>> in a future release.  For those who are unaware, the KFM KLL plug- 
>>> ins
>>> have been used in previous releases of MacOS X to allow the Kerberos
>>> initial ticket getting functionality to be extended such that
>>> whenever a
>>> new Kerberos 5 Initial Ticket is obtained a new AFS token would be
>>> acquired at the same time.  Without this functionality it is not
>>> possible to provide a single sign-on experience for AFS on Tiger.
>>
>> (Remember, I'm just a developer who happens to work at Apple; I don't
>> speak for Apple.)
>>
>> It turns out I was working this week on something similar, a PAM
>> module for aklog.  This is still highly experimental, but I have
>> modified aklog to be more reentrant and embeddible, by converting all
>> the global variables into fields of a structure.  I have add an
>> additional routine that allocates such a structure, which is then
>> passed to the aklog() routine.  So now, the main() routine of the
>> aklog program calls alloc_aklog_globals() to get a block of memory,
>> and passes that to the aklog() routine with the arguments.
>>
>> The PAM modules does the same thing.  There are some differences that
>> are taken care of with a macro definition, like the fact that argv[0]
>> is the name of the aklog program, but is the first real argument from
>> the PAM modules.  Also, the aklog program exits on error; the PAM
>> modules does a longjmp back to the aklog() routine to do an error
>> return (because there is no exit, there might be some memory leaks or
>> other cleanup that will need to be done).
>>
>> Creating a loadable PAM module did present some problem.  The LWP
>> code uses assembly language (process.s for ppc and process.i386.s for
>> x86), but that code references a global variable in way that would
>> require a writable text segment.  So I added the usual assembly goop
>> to move the relocation info to a data segment.  (I had tried to
>> replace LWP with the pthread code, but was running into a bunch of
>> undefined symbol problems, so I fell back to LWP.  I did notice four
>> places that allocate pthread mutexes but don't initialize with
>> PTHREAD_MUTEX_INITIALIZER as per POSIX, and would have made a
>> difference on Mac OS X, since when uninitialized, it would reside in
>> common segment, which is not allowed for a bundle.  Initializing it
>> moves it into a data segment.)
>>
>> So I finally created the PAM module, which only does session open and
>> close.  The open calls aklog to create the token.  The close does the
>> equivalent of unlog, but I then commented that out, since I can
>> imagine being logging into the GUI, when an ssh session comes in,
>> renews the AFS token and then removes it on logout, leaving the GUI
>> without a token.  Some mechanism for the last-one-out removing the
>> token is needed.
>>
>> So fine, I have a PAM module, but so what?  Well, I also wrote a
>> loginwindow "LoginHook", that is called loginwindow_pam_helper.  It
>> gets run when loginwindow finishes authenticating (presuming /etc/
>> authorization is set up to do Kerberos authentication).  It then does
>> the usual PAM stuff to open a session and I set up the PAM config
>> file to call my pam_aklog module.  In loginwindow_pam_helper, I use a
>> kqueue to monitor when loginwindow terminates (usually when the user
>> logs out, or if loginwindow dies) and then close the session.
>>
>> Well, this actually all works!  I log in, and my AFS tokens are
>> there.  I can even set up a .xlog file and get tokens for multiple
>> cells.
>>
>> Now I'm not saying this is the best approach.  My thinking was that a
>> PAM module would be useful for other Unix platforms as well, but
>> doesn't really fit in so nicely in Mac OS X.  The KFM might be a
>> little cleaner, though Mac OS X specific.  But it might be possible
>> to get loginwindow to do PAM directly, so my loginwindow_pam_helper
>> wouldn't be needed anymore, and then the PAM module might fit in
>> better (of course, I'm not on the loginwindow team, so I can't say
>> they will make this change).
>>
>> Mac OS X also has it's own way of doing things, like the
>> Authorization Services framework.  Now I'm a Unix guy, so the
>> Authorization Services framework is new to me.  But it might also be
>> feasible to put in aklog as a plug-in.  Then loginwindow could get to
>> aklog through Authorization Services, and since there is already a
>> pam_securityserver.so module that calls into the Authorization
>> Services framework, things like ssh might also be able to get to
>> aklog.  Again this is Mac OS specific, but could be the cleanest way
>> for both Mac OS X applications and command-line programs to get aklog
>> access.  And since aklog is embeddable, we could build the aklog
>> program, the aklog PAM module, the aklog Authorization plug-in and
>> possibly even the KFM KLL plug-in, all using the same base code.

;-)  See my comment at the top.

I think part of the problem is that Apple hasn't integrated Kerberos  
into the login process properly.  Alexandra pointed out some specific  
issues that OpenAFS needs to deal with, but I note that the Tech Note  
on how to modify /etc/authorization to use Kerberos during login  
still hasn't been updated for 10.4.  JPL has made it clear that we  
want that through the proper channels.  (I wonder if that's even the  
right way to do it though.  Hence my question about how DS and Auth  
Svcs relate.)

>> Anyways, Derrick, let me know if I can be of help with the KFM KLL
>> plug-in (which is something else I don't know much about).
>
>
> The problem with using a pam plugin is that it won't run every time  
> new tickets are acquired.  The KLL loginLogout plugins even run  
> when Kerberos.app is automatically renewing your tickets. It is  
> this seamlessness which probably originally inspired Henry Hotz to  
> want to use the presence of the afs service ticket to indicate that  
> afs tokens had been acquired.

Just trying to make a good thing better.  ;-)

>   Now you could write a loginLogout plugin that calls pam modules,  
> but that will just land you back at the problem I described above.
>
> You can actually hinge successful Kerberos ticket acquisition on  
> successful AFS token acquisition.  The loginLogout plugin API  
> allows the plugin to cancel ticket acquisition if the plugin  
> fails.  However this means that if you can't get AFS tokens, you  
> also won't be able to get tickets -- probably not terribly useful  
> unless you have an AFS home directory -- then no tokens really does  
> mean you can't do anything.

Agreed, not what we want.

> As a side note the loginLogout plugins are called for all ticket  
> acquistion.  So if the user has two identities such as user at REALM  
> and user/admin at REALM, the plugin needs to be smart about how it  
> gets tokens when the plugin is called for both of them.

In this case you get tokens when you can and you don't when you can't  
(like user/admin isn't in AFS).  I believe our existing AFS kernel  
code can keep track of the tokens as-is.  If the Kerberos GUI showed  
afs service tickets only for those identities that got valid afs  
tokens and not otherwise then we're good.

--

Just to bring another issue into the discussion.  What about if we  
use something besides Kerberos to get AFS tokens?  Apple seems to be  
headed in the direction of using the Keychain Manager to show PKI- 
based permissions.  That's a pretty disjoint GUI from Kerberos.app.   
My belief is that that's far enough off that it's worth doing  
something about the UI confusion with tokens and Kerberos anyway.   
Something to ponder in odd moments.
------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu