[OpenAFS] The Illusion of Security

[Rodney M Dyer]

At 08:34 AM 8/18/2003 -0400, Sam Hartman wrote:
>It's probably a good idea to at least copy one of the MIT Kerberos
>lists on bugs yu find in our code.  We don't tend to read the OpenAFS
>lists and we don't suddenly become aware of issues that aren't brought
>to our attention.

I was actually very close to doing that until I got mail from my MIT friend 
that said the problem was intentional.

>    Let's assume that MIT's kinit for KFW did accept passwords on
>     stdin.  Would you have had to modify any of the AFS code or is
>     there already a facility for starting a shell during the afs login
>     process?

Smart, you've caught me.  There is no built-in facility for starting a 
shell in OpenAFS.  I make a small change to "afslogon.c" to exec a shell at 
the point where K4 authentication is normally done.  This small change 
requires no extra compile-time headers, or run-time dependencies.  This is 
known as the AFSLogonShell.  See...

http://www.coe.uncc.edu/~rmdyer/afslogonshell.htm

Frankly, I'd love to see this "shell" facility added into OpenAFS.  It 
actually makes AFS on Windows much easier to manage because it solves -so- 
many problems.  Example...

1.  K5 authentication can be done using "off-the-shelf" binaries..."kinit" 
& "aklog".  I can override the internal K4 authentication if I want, or 
allow the error status to be processed.
2.  Roaming profiles are easier to setup.
3.  Folder redirection is much less complicated to setup.
4.  The AFS service and global drive can be tested at user logon.
5.  Quota and user volumes can be checked at logon.
6.  The shell exec can be configured to call any scripting language 
interpreter or process.

Without the shell feature we are limited to the current K4 authentication 
of "afslogon.c" and there's no way to perform any logon scripting before 
the user's process space has been init'ed.  Microsoft's logon scripting is 
limited to the post-init environment.  At that point, folder redirection is 
all but impossible to setup.

I could rave all day about how much I like the "shell" feature, it doesn't 
change the fact that anyone can download the code and do what I did.  The 
"afslogon.dll" file is simply a Microsoft logon provider.  There isn't 
really anything special about the fact that it does AFS 
authentication.  It's just a DLL file that exports certain functions to the 
Winlogon process.  You can add multiple logon providers just like you can 
glue together pam modules.  I "could" have written my own logon provider 
DLL and "shelled" out of that.  That wouldn't have been any different.  I 
just thought, hey, why write my own, here's a perfectly good one that ships 
with OpenAFS.  All the logon providers "get" the plaintext password.

Why can't you guys modify "kinit" so that it check to see of the username 
is "system"?  If it is, then you allow the pipe, if not, then dont.  Simple 
enough?  Oh, not so simple, this won't work on Win9x series...

Rodney