Ken Hornstein wrote: >> This is the strange part: no such power exists here. >> >> Maybe it's "a Berkeley thing". My personal interpretation is that >> people act as if "nothing is any more official than the number of >> people you've persuaded to rely on it". The majority of the people in >> the department retain exclusive administrative control of their own >> workstation. This is true in many other departments here as well. > > I feel your pain; I'm in the exact same situation. Multiply this by 50 > different organizations, and you realize that it's a tough problem. > > The difference here is that our users _have_ to use our systems to get > their work done (research grant money hinges on this). As a result, > they are highly motivated (someone else might used the word "forced") > to download our software and configuration files. If you don't have > this kind of leverage, I can imagine that you'll be fighting an uphill > battle. The pain of dealing with this is the reason I'm willing to > trade what I believe is a small security risk (getting configuration > information in an insecure manner) for what is a HUGE gain in > manageability. Sadly, decisions were made along the way to make it so > the default out-of-the-box system setup was tilted more toward security > rather than manageability. To be fair, this is more related to > Kerberos than OpenAFS ... you should be bugging the Kerberos people > about that (but the reception you're going to get there will be even > frostier than the one you've gotten from the OpenAFS people). > > --Ken
I am a strong believer that security is meaningless if it is so difficult to use that end users will ignore it. The lesson I took from SSH was that for the vast majority of users and administrators it is acceptable for the configuration data (the host's key) to be obtained once via an insecure manner and then warn the user if the data ever changes. I could conceivably add code to the Identity Manager that would obtain data from DNS in an untrusted manner, cache it in the form of configuration data with a time stamp and marker of some kind, and then annoy the user if things change. This is not going to be as secure as manually distributed config files but would be more secure than always querying DNS. Its just a thought. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
