[cap-talk] Windows Vista: security by admonition

[Micah Brodsky]

My point about the hazards of a privileged shell was particularly focused on
traditional user-granularity systems. By a shell, I mean program launching,
file management, and job control. (GUI is what I had in mind, though David
Hopwood's point about needing a solution for command-based shells is well
taken.) These functions are separable, though I don't think separation helps
here.

In a user-granularity system, even after closing off hostile IPC mechanisms,
the amount of shared (personalizable) shell configuration state, environment
configuration state, and GUI state is likely to be large. Such a shell, if
granted special privileges beyond the basic user privileges, would not
likely keep those privileges confined. It seems kind of awkward to hoist all
this shared state to a higher privilege level within an existing system,
though perhaps you could do it with a clean-slate.

On the other hand, I think with a real secure capability system, you'd
actually have a fighting chance of getting the shell right. I don't think
you can get away with just having a privileged program launcher. You need a
way to designate permission on files, jobs, and the like as well, and the
code that administers this needs to be privileged. I don't have enough
intuition to know how easy it would be to build this securely while catering
to user needs like cushy UIs, flexibility, accessibility, and all that, but
it may well be doable.
(Although, most prior, practical GUI systems have shown a distinct tendancy
towards extreme internal complexity, which is discouraging.) 

The example we've been talking about is an interesting case, though. Rather
than administering the user's ordinary privileges, UAC is about
administering extraordinary privileges, those that modify global system
state. These are privileges beyond the ordinary needs of users, and from
this perspective, it makes little more sense to grant them unconditionally
to the user's shell than it does, for example, to grant the user's full
privileges to a web browser. Instead, by going out of band to a very
compact, trustworthy broker to request particular privileges in the rare
cases they are needed, a lot less code needs to keep administrative
privileges around.

This is not to say that such a mechanism needs to follow the admonishment
paradigm instead of the designation paradigm, but it's frequently a lot
easier to write a mechanically secure broker for admonitions than it is to
write one for designations. This is what I mean by the potential hazard with
designation. 

For the case of extraordinary permissions, though, I'm not sure that
admonishment can't also be made useably secure. In many systems, it is
already common for "dangerous" actions to be accompanied by admonitions. For
example, most GUI file managers ask you to confirm file deletions, and users
seem happy with this. I, for one, have accidentally issued delete commands
on occasion, and the resulting admonishment triggered the appropriate panic
response, not the "stupid dialog box" reaction! Since many administrative
actions have a similar "dangerous" nature, the admonishment paradigm may
well be reasonable if done well.

I'm not entirely sure of all the reasons why admonition works so well in
some cases, but my conjecture is that it is because the user understands
that what they're doing may be dangerous, and there is a crystal clear
relationship between the user's action and the resulting confirmation. If
confirmations are highly consistent, rarely superfluous, and always phrased
in the user's own terms rather than the system's terms, users may assimilate
them well. In the classic failures of web browser and email enclosure
admonitions, it was typically unclear either what was being confirmed, why
it mattered, or what the user had done to trigger the confirmation, and
false warnings were frequent. There were no clear rules anyone could have
written let alone inferred for when to say yes and when to panic.

(Lately, I've been brainstorming some possibilities for improving the way
admonitions are phrased by using Asbestos-style information flow control.
For privacy, in particular, it seems like there may be some benefit. If you
can tell the user in their own terms (e.g. "your address book") what
information is in question and where it could be going, maybe the user will
know what you're talking about. Not sure if this will go anywhere yet...)

--Micah