[cap-talk] Windows Vista: security by admonition, overview and comments

[Jed at Webstart]

Cap-talk,

Quite a bit of material has gone by already on this thread, particularly Toby's
initial summary and quotes.  Enough so that I'm not sure whether I can
make any helpful comments.  I have read it all.  I think perhaps I can
contribute best by starting from a general position and then getting
to specific comments.

Firstly I think it kind of sad that so few people (even people on this list)
have direct experience with capability based (generally POLA) systems.
While many (most, all?) instances of such systems (certainly the
two that I have most direct experience with) don't support all the features
of many modern operating systems (e.g. shell piping, GUI features,
etc., etc.), I expect anyone who has worked on such systems
sees no barriers to introducing such features and still staying faithful
to the underlying POLA nature of the systems.

I should also restate my opinion that providing such features with on
a POLA base (with communicable authority tokens - e.g. "capabilities")
isn't difficult or complex, but is simply a matter of making reasonable
local parameter passing decisions at well defined interfaces.  In such
an environment the difficult to impossible global decisions that are often
faced by systems today (e.g. SetUID programs, etc.) are completely
avoided.

So what to make of "Windows Vista" and their "User Account Control"
in that context?  I guess all I can say is that it seems a worthwhile,
though limited effort considering where they are coming from.  As I
see it, if they succeed with this rather difficult project then they will
have succeeded in getting Windows to about the same logical level
as Unix systems are at regarding access control - which is a rather
pitiful position, though better than the current state of Windows.

I generally agree with Toby's assessment:

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

Hopeless in the sense of never being able to do anything like "the right
thing", but perhaps not hopeless in the sense of improving the current
Windows situation.

Dropping one level down into the comments, regarding Micah Brodsky's:

"Shells are big,
complicated, extensible, and highly environment-dependent. Explorer is a
particularly bad example, supporting zillions of legacy in-process
extensions (e.g. right click to WinZip, browse pocket PC contents, etc.),
capable of embedding the entire web browser, and, I suspect, frequently
abused by applications via IPC. 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."

I think there are two basic problems or misunderstandings that seem to
be contributing to the view that there are fundamentally difficult problems
here (besides trying to be backward compatible with a mess):

1.  There seems to be a notion (born I guess from Unix implementations)
that a user command environment and a shell execution environment
are or should be one and the same.  This certainly need not be the case.
I'm not sure how far plash pushes this, but a user command environment
can (and I think in a POLA context probably should) be quite a simple
and easy to understand interface focusing on passing parameters
(including authorities) to program execution environments - with none of
the complexity of extension, environment dependence, complexity, etc.
mentioned above.

Shells in the sense of interpreters like csh or bash or perl or ... are really
execution environments which themselves need to execute in POLA
environments defined by their intended use.  There is one place where
I see some natural tension here - namely when quickly defining new
programs (e.g. from combining simple scripts) that then need to have
their interfaces restricted appropriate to their resource requirements.
It might be that it would be difficult to make the parameter passing
for the initialization interface as quick and easy as the program definition.
Still, I think that is the relatively rare case and not of concern to the vast
majority of users.

2.  The common acceptance and seeming even inevitability of
the "ambient authority" ("user" authority based on "who" a
process runs as) model of authority.   This basic model makes
confused deputies nearly inevitable and complicates simple
resource sharing to the point of making it effectively impossible
to do POLA computing.  The point about the nightmare of writing
secure SetUID programs is right on, but the lesson of seeming
to deny the value of starting from a trusted user command
interface that parcels out authority as needed I think is misplaced.
The problem that it instead points to is that of the ambient authority
model of computing - whether files with UGO RWX or ACLs or
really any other sort of "user" based model.  It just doesn't and
really can't work.

We need to build away from that basic model.  Unfortunately since
so few people and even fewer (any?) people of influence are even
aware of the basic problem, it's a pretty discouraging situation.


Then diving down one more level of detail to comment on other
comments:

I think what I said in #1 above is about what David Wagner said:

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

I also agree with David Wagner when he responds:

>David Wagner replies:
>Micah Brodsky writes:
> >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.

I would go further to argue that "security by designation" (which I
think of simply in terms of communicating authorities just as
one does any other parameters) doesn't by itself introduce any
security risks (as Micah Brodsky seems to fear), but rather provides
an environment where at least security environments and communication
can be effectively defined.

regarding:

>David Wagner replies:
>Micah Brodsky writes:
> >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.

I think it's simply trying to get Windows to about where Unix is.  Namely
under Unix users are typically able to do all their work with their
ordinary "user" level privileges.  With Windows users seem to need
administrative (equivalent of "root") privileges so often that running as
an administrative user is common.  UAC, if successful, will simply
let Windows make use of the more restricted authority typically
granted to ordinary "users".

Still, I agree with David Wagner and I guess Micah Brodsky that
this really doesn't go very far in helping with the general security
problems.  Unix has equivalent problems with Trojan horses that
run with full user privileges - even if not typically with root
privileges (even disregarding "hacking root" via privilege
escalation).

This really is a sad state of affairs, isn't it?

To touch on a later point in the thread:

>David Hopwood writes:
> >David Wagner wrote:
> >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.
>
>Well, I'm not disagreeing.  I'm not agreeing, either.  I'm deliberately
>not taking any position about whether it is feasible to build a
>trustworthy shell/launcher with all of these features.

I'd just like to clarify that I think part of the tension in this discussion
is the juxtaposition of "shell" and "launcher".  I believe these functions
can and should be separated, with the "launcher" (one might call it
a parameter communicator) being a simple, tight, and trusted
user interface that allows one to execute other programs, including
such things as shell scripts and anything else under suitable
POLA control.

I agree that the concept of SetUID is a disaster.  I agree that current
Windows, and to only a very slightly lesser extent Unix, access control
schemes based on ambient authority ("user"s) are an impossible
disaster from a security perspective.  This Windows Vista UAC
effort, as heavy as it might be to implement, only provides a tiny
boost in Windows security to make it more comparable to Unix
security - which is itself a disaster.

So ... where to go from here?  I still believe that doing the right thing
(POLA, communicable authority tokens) at the network level (e.g.
YURLs, widewords, etc.), demonstrating its viability (e.g. for
resource sharing - perhaps like with Google's new spreadsheet
application), and then driving that paradigm down to the OS level
is the most likely approach to succeed.

Windows Vista and UAC is not on any path to "success" IMHO.
Efforts like Plash and Polaris can at least be considered more
helpful - e.g. as efforts like E and modern capability operating
systems.  However, I see such efforts more along the lines
of continued re demonstrations of a basic principle that to me
shouldn't need to be demonstrated again and again.  What's really
needed is a practical path to change the basic authority paradigm
for computing.  To me starting at the level of the network is the best
hope.

--Jed http://www.webstart.com/jed/