[cap-talk] Windows Vista: security by admonition

[David Hopwood]

David Wagner wrote:
> 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.

I don't see why it isn't feasible to specify complex pipelines, job
control, command-line editing, and program arguments in a secure shell.
None of these are rocket science.

If we can't write a secure command-line parser (assuming no compatibility
constraints), then we might as well give up on ever building secure computer
systems.

>>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.

This is a very important point. Another important point is that the
shell would be written in a language that is at least memory-safe, and
preferably capability-secure, so there would be no way to "take over" the
shell through exploits that involve undefined behaviour.

(The language implementation does not need to be bug-free in order for
this property to hold in practice.)

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>