E_ACCESSDENIED? Good. We did OUR job.
One of the security groups at Microsoft used to have T-Shirts that said this; every time I saw one, my blood pressure went up. He's a story illustrating why:
Scene: A home office, fall, 2003. Our hero has just bought a new Macintosh (probably OS 10.0 or 10.1) for his wife, and is trying to configure things such that it can access shares on the existing Windows Server 2000 machine. He's wearing out a path in the carpet between the Mac and the server.
(At Mac): Access denied? I must have typed the password wrong. Let me try again. No luck.
(At Server): Maybe I set the password wrong at this end. Let me reset it.
(At Mac): Still no luck. I wonder if I have problems with the ACLs.
(At Server). The ACL looks OK. Just to be sure, let's temporarily set it to full access for everyone.
(At Mac). Still won't work.
(At Server). Oh, there's an ACL on the share as well as the directory. Let's set it to full access for everyone, too.
(At Mac). Still out of luck.
With a focused determination seen only in those afflicted with a touch of both ADD and autism, our hero flounders around, investigating every possible configuration option on both the Mac and the server. Whenever he finds some restriction that looks like it might possibly be relevant, he loosens it. Eventually, he stumbles across the Group Policy Editor on Windows, where he finds things with intriguing names like "Network Security: Minimum session security for NTLM SSP-based (including secure RPC) clients" and "Domain Member: Digitally encrypt secure channel data (when possible)". He messes around with these and other likely-looking settings, to no effect.
After a while, he has a brainstorm: Maybe some of these setting changes don't take effect until I reboot, he thinks. So, he reboots, and voilà, things work!
It's now 2:00 AM, and he's been at it four hours longer than intended. He decides to go to bed, and clean up the mess tomorrow.
The next day, he can't remember which settings he changed, and has no clue as to which of them was the relevant one. (With his luck, there probably wasn't a relevant one, but two that were each necessary.) There's no way he's going to find out which settings were relevant. "Screw it. It works; leave it alone."
There are two morals here:
First, more security is often less. Microsoft has a nice "Secure by design, Secure by default, Secure by deployment" initiative. Unfortunately, the security that the user gets is not the security that you designed, not the security that you turned on by default, and not the security that you deployed. It's the security that's left standing after he makes everything work. If there are 50 security gates in your system, and the customer's desired workload needs to make it through three of them, the non-expert administrator is likely to turn off 40 of the 50 gates before he disables the three relevant ones.
Second, it's important to realize that not every request that is denied by a security gate is in fact malicious. It sure would be nice if the system were to say "I rejected such-and-such a request for such-and-such a reason, and if you intend me to accept requests like this, you need to change the XYZ policy." Now, security experts will tell you that you shouldn't tell an attacker exactly why you rejected his request, and they're right. However, you should tell the system administrator, in case it wasn't really an attack, but someone trying to get legitimate work done.
When I'm supreme dictator of the universe, anyone who writes code that returns E_ACCESSDENIED will be required to create an event log entry saying what software component did it, why, and what setting to change in what piece of UI if this wasn't the desired outcome.
Postscript: I think it was the "Domain Controller: Digitally encrypt secure channel data (always)" policy, and I think it's because early versions of Mac OS X shipped with a version of SAMBA with a bug. But I'm not sure on either account.
.jpg)
No comments:
Post a Comment