KfM 4.0b7: a few questions

Marshall Vale mjv at MIT.EDU
Thu Jan 31 11:05:00 EST 2002


At 1:13 AM -0500 1/31/02, Ken Hornstein wrote:
>I have to believe that changing the library _not_ to pop up a dialog
>box can't be that big of a change, and there are certainly plenty of
>places to stuff the information to tell the library how to behave.

Ok, so if you remove the ability for the dialog to pop up, how does 
it ever get displayed? What triggers it?

New APIs? Ones that any trojan application can call itself?

A list of privileged applications? One that can be hacked or impersonated?

Put yet another copy of the dialog and associated libraries in a 
privileged application? That's a code synchronization mess. Remember, 
right now the dialog and associated items are in the library, not any 
specialized application.

>When you get right down to it, in a system with a nice graphical UI, 
>you _expect_ things
>to be helpful, like putting up a password dialog when you need to enter
>your password.  But I agree it's important to train users to only enter
>their Kerberos password into the few places where Kerberos passwords
>go.

It gets worse on an OS which has multiple types of user interaction 
each with their own history of standard user interaction.

>  But ... if you can pop up a dialog box onto someone's screen,
>then the game is already over IMHO.  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).

And that gets right down to the point, I don't know of any either. 
There are enough sites with other concrete requests that features for 
hypothetical situations aren't exactly appealing.

I still say that even if you truly disable auto-dialogs, you're only 
moving the problem laterally. Now you just need a trojan to 
impersonate the privileged application. If you want to get rid of 
dialogs, you should implement a system with Kerberos that never needs 
user UI (dialogs or CLIs or whatever) interaction, such as one of 
those Kerberos SmartCard projects.

Marshall



More information about the krbdev mailing list