[cap-talk] Windows Vista: security by admonition

[Toby Murray]

Hi cap-talk,

Don't know if anyone's still following this one, but a new post on 
Vista's User Account Control is a little illuminating, if only for the 
insight it gives into the mindset of the guys who are working on this 
thing. It appears to me that they've decided that the internal structure 
of Windows makes some problems difficult to solve (such as being able to 
infer the amount of authority to attach to UI events) and that 
therefore, these problems have to be shifted back to the user to solve. 
Hence, these UAC dialogs.

http://blogs.msdn.com/uac/archive/2006/06/01/613098.aspx

Some quotes

> Question 1: Why does Windows ask me for permission when I JUST double 
> clicked on the executable or clicked on the shielded object?
>
> The issue here is extensibility of Windows. Windows prides itself it 
> on being pluggable and extendable. For example, to facilitate the 
> accessibility extensions, Windows needs to be able to send keystrokes 
> on the user’s behalf so that a Windows user can talk to an input 
> device and have that be translated into keystrokes that drive a dialog 
> or type an email message. This also allows interesting and useful 
> scenarios such as “show me how” buttons inside help dialogs.
>
> However, that means that malware, running as a Standard User, can 
> download an administrative application, and send keystrokes through 
> Windows to simulate the user invoking the application. As a result, 
> Windows cannot tell if YOU launched the application or if malware 
> launched the application.
>

Compare this with Ping's recent blog post on this very topic: 
http://usablesecurity.com/2006/05/18/vista-security/

>
> The question isn’t “How can the system figure out whether the user 
> really wanted this file deleted?” It’s “Why did the system forget that 
> the user wanted this file deleted?”
>
> The designation of what action to do — delete the shortcut — has 
> become separated from the authorization to do it. That leaves the file 
> system stuck with the problem of obtaining that authorization from 
> some other source, which is bound to be inaccurate. The design lesson, 
> therefore, is never to separate designation from authorization. 


As a cap enthusiast, of course I agree with Ping here. Applied to the 
keystrokes issue above, one could tag the source of the keystrokes. 
Keystrokes coming from input drivers (for your keyboard or your voice 
recog device) are treated differently than keystrokes generated by an 
ordinary application. This is basically just authority-via-identity (cf. 
ACLs), but would achieve Ping's goal of attaching authority to the 
designation but without having to put in something as foreign as caps 
(authority-via-connectivity).

On a broader note. In response to Question 1, the anwer continues with this

> Once that is true, we can then move to educating the users to know 
> that “good” elevations are ones that they initiated and “bad” 
> elevations are ones that suddenly appear without their explicit 
> action. We want the users to think “if an elevation dialog appears 
> while I am reading my email, and I didn’t perform any action that 
> would require elevation, always cancel those dialogs.”

As Ping points out, figuring out whether or not the user initiated the 
action cannot be done unless some sort of authority is attached to the 
designation. (Whether one uses caps or instead tags each designation 
with the source identity and then does an identity to authority map is 
probably unimportant at the moment). As I said above, this UAC mess 
looks to me like an exercise in shifting the burden of making this 
decision back onto the user. When even the UAC Lead Program Manager 
thinks that the problem can't be solved by Windows and must therefore be 
shifted back to the user to solve, the situation looks hopeless.

I'm sure there's a usability principle that says "if the machine can do 
it, don't force the user to have to do it". I know there's security 
principles that say "the user might be the weakest link" and "security 
is only as strong as the weakest link". Therefore, shifting the burden 
back onto the user is of course bad for security and usability.


-- 
Toby Murray
Advanced Computer Capabilities Group
Information Networks Division
DSTO, Australia

IMPORTANT: This e-mail remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this e-mail in error, you are
requested to contact the sender and delete the e-mail.