[cap-talk] Windows Vista: security by admonition

David Wagner daw at cs.berkeley.edu
Mon Jun 5 04:00:45 EDT 2006

Micah Brodsky writes:
>More fundamental than needing trusted input is having a privileged,
>protected shell.

I'm not quite sure what you mean by "shell".  Are you referring to
something like a Unix command-line shell, such as /bin/sh, bash, zsh,
tcsh, etc.?

If so, I don't see any reason why you would need a full command-line
shell.  If you're building a GUI system along the lines of MS Windows,
all you need is the ability to launch new programs in response to user
requests.  You don't need to be able to specify complex pipelines,
job control, command-line editing, arguments, etc.  Yes, the program
launcher is part of the TCB, and yes, it needs a trusted path to the
user.  But I see no reason that a program launcher needs to be complex
(and certainly no need to be anywhere near as complex as Explorer).
It seems eminently feasible to build a secure program launcher.

>Even with a cleaner, more self-contained
>shell, the vulnerability exposure due to state shared under this mechanism
>would be staggering -- consider how much of a nightmare writing secure
>SetUID programs on Unix has proven to be. 

The analogy to Unix setuid doesn't apply.  Part of the problem with Unix
setuid is that, on Unix, any old program can invoke any setuid program,
and there is a lot of context that is inherited from the invoker to
the invokee.  But in CapDesk (for instance), only the user can instruct
the program launcher to launch a new program; programs can't spawn other
programs via the program launcher.  Consequently, a program launcher
doesn't provide a way for one program to attack another, and context
isn't inherited from the attacker to the victim.

I don't see why you expect a program launcher would create a lot of
shared state.  I would that, in a well-structured capability-oriented
system, applications would by default receive no access to any mutable
shared state, except for that which was explicitly approved by the user
(e.g., by some explicit user action, such as double-clicking on a file)
or provided as part of the application's installation process.  Capability
systems strive to reduce the amount of mutable state that is shared between
applications to the bare minimum needed to get useful work done.

>As much as I agree that "security by designation" leads to better practical
>security than "security by admonition", I think it has to be balanced
>against the technical security risks it introduces. In this particular case,
>the problems seem to me to be too daunting.

I guess I'm having trouble understanding what technical security risks
you expect "security by designation" to introduce.

>All that being said, I'm not really sure what UAC is trying to accomplish in
>terms of security for ordinary desktop users. Running with only user
>privileges, malware can [do all sorts of nasty stuff]

A good question.  I'm not too clear on that, either.

More information about the cap-talk mailing list