KfM 4.0b7: a few questions

[Alexandra Ellwood]

I'm unclear why is it such a problem to train users to only type 
their password into the Kerberos Login Server dialog.  We present a 
distinctive and consistent user interface, Dock icon and launch path. 
Our KerberosLoginServer.app (separate from the Kerberos.app) resides 
in a location owned by root/wheel so admin users can't modify it 
without typing in their admin passwords.  Any security conscious user 
can verify via their favorite process monitor that only a user with 
root access could have tampered with their Kerberos dialog.

Non-security conscious users aren't going to verify anything, no 
matter how hard you try to make them.  In fact if you make life too 
difficult for these users, they'll find a way to circumvent the 
security entirely.  Mac users are intolerant of inconvenient 
applications -- much more so than Unix users -- especially since 
Kerberos has been historically more convenient on the Mac.

Training users to run "kinit" when they get a "no credentials" error 
is very similar to training them to type into a specific-looking 
dialog which appears when credentials are not present.  Yes, a 
malicious application can launch a helper application that presents a 
similar looking dialog.  That same app could also add a line to the 
user's .cshrc which makes "kinit" an alias to a malicious kinit.  Or 
it could change the Kerberos application icon in the Dock to point to 
a malicious Kerberos application.  If the user is an admin user, the 
situation is even worse, because /Applications is writable by the 
admin group, and the malicious application could modify the Kerberos 
application itself.

In order to notice this kind of tampering, users need to run "alias 
kinit", avoid the Dock, or check the mod dates on the Kerberos 
application before typing in their password.  Any user willing to do 
that would also be willing to run "/bin/ps" to verify that the real 
Kerberos Login Server is prompting for a password.

If you're going to spend lots of resources training users, you should 
train them to only download and run trusted software.  At the very 
least, instruct users to create a separate non-admin, non-Kerberos 
account for recreational software.  Once malicious software is 
running as the user, you've already lost.  Even if the malicious 
program doesn't bother attacking the automatic Kerberos dialog, it 
still has access to the ticket file/cache, the dock icons, etc.

>But it wouldn't surprise me if a
>site had a policy prohibiting the auto-password dialog from being used,
>and it would be shame if you couldn't use the shipped Mac Kerberos
>at such a site (not that any site that I'm aware of has such a policy
>today).

If a site has such a policy, they won't be able to use Mac OS X at 
all.  Mac OS X automatically prompts for passwords all over the 
place, especially for the admin password to get root access.  In the 
not too distant future, this admin password could also be the user's 
Kerberos password.

In addition, any site handling very sensitive information on Mac OS X 
or Windows boxes should have a disconnected network or no network at 
all.  Automatic prompting for passwords is the least of their 
problems.


However, Alexei's automatic AFS token acquisition program exposes a 
technical problem in the *way* we automatically pop up dialogs.  We 
will investigate ways to fix it in a future release.  It probably 
won't make it into 4.0 though.


Fortunately with the Kerberos.loginAuthenticator, users can get 
tickets on login (via the loginwindow).  When the login authenticator 
is enabled, the automatic dialog should only pop up if users 
intentionally destroy their tickets, or if the tickets expire.


My two cents,

--lxs
-- 
-----------------------------------------------------------------------------
Alexandra Ellwood                                               <lxs at mit.edu>
MIT Information Systems                               http://mit.edu/lxs/www/
-----------------------------------------------------------------------------
--