[cap-talk] Windows Vista: security by admonition
david.nospam.hopwood at blueyonder.co.uk
Mon Jun 5 09:58:31 EDT 2006
David Wagner wrote:
> Micah Brodsky writes:
>>More fundamental than needing trusted input is having a privileged,
> 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
>>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>
More information about the cap-talk