[cap-talk] Microsoft

[David-Sarah Hopwood]

Matej Kosik wrote:
> Ben Kloosterman wrote:
>>> Does any Microsoft product has all the following properties?:
>>> - it (and its components) follow POLA
>>> - it is defensively consistent (or even defensively correct)
>>> - it has tiny TCB
>>> - it has minimal reliance relationship.
>> None;  I don't think any of these are possible while maintaining backward
>> compatibility, and their customers have always told them compatibility is
>> more important than security.
> 
> You are right if you talk about legacy software but there are no excuses
> if you are writing new software. Comparing object-capability security
> model and schemes like this:
> 
> @article{1273033,
> author = {Ted Wobber and Aydan Yumerefendi and Mart\'{\i}n Abadi and
> Andrew Birrell and Daniel R. Simon},
> title = {Authorizing applications in singularity},
> journal = {SIGOPS Oper. Syst. Rev.},
> volume = {41},
> number = {3},
> year = {2007},
> issn = {0163-5980},
> pages = {355--368},
> doi = {http://doi.acm.org/10.1145/1272998.1273033},
> publisher = {ACM},
> address = {New York, NY, USA},
> }
> 
> I do not believe that Singularity or Midori will be any better than
> Vista, from security point of view.

Judging by that paper, I'm forced to agree.

Consider the following:

# 3.1 Processes, channels, and endpoints
#
# Each process acts under the authority of one principal and that
# principal's name is by default associated with all endpoints the
# process owns. Processes can transfer authority by transferring
# endpoints or delegating rights to other processes; however, the
# principal name associated with transferred authority always
# identifies the holder. One or more processes derive from loading
# and running an application. An application is described by a manifest.
# The principal name associated with a process derives from its
# application manifest and the principal name of the process that
# invoked it. The Singularity kernel allows a process to discover
# the principal name associated with the partner of any of its
# endpoints. The resulting principal name is then used to make access
# decisions pertaining to messages received over channels. Thus,
# access control in Singularity is discretionary.
#
# Singularity endpoints can move. To determine that a message was
# sent by a specific process, the partner endpoint must not move
# between when a message it sent and when its recipient observes
# the sender. To enforce this, Singularity imposes static restrictions
# on the movement of endpoints. An endpoint can move only from a
# process via a message send, and then only if the local endpoint
# state machine is in a state that allows that process to send.
# Therefore, when a server receives a request on a channel, the
# server can know that the partner endpoint has transitioned from
# send to receive state, and thus the principal associated with
# the partner endpoint must be the same as when the initial message
# was sent.

It's pretty obvious that what the first paragraph above describes
is absolutely the wrong way of doing access control, but I want to
focus on the second paragraph, because I think it's even more
instructive.

So: for the sake of argument, you have have a microkernel OS in
which the kernel provides channels between endpoints that belong to
principals (but can move between them), and you want the recipient
of a message to be able to authenticate the principal that sent it.

There is a completely obvious and straightforward way to do this:
have the kernel associate the sending principal with the message
itself (for example, by giving the principal to the receiver at
the same time as the message).

Do the Singularity designers do it the straightforward way? Noooo....
That would be just too easy. They manage to identify the TOCTTOU bug
that would occur if the receiver asked for the sending principal in
a separate kernel call. But the way they choose to fix it is about the
most error-prone, non-compositional, fragile (in the sense of depending
on other design decisions that should be orthogonal), and non-local
("let's extend the reliance set of one process to the state machine
for another process just for the hell of it") way you could think of --
or that you probably wouldn't think of, actually.

This is *absolutely typical* of Microsoft design. There's something
about the culture and environment of the company, that turns intelligent
people with a good sense of design aesthetics (Martín Abadi has done
really excellent work in cryptography, type theory, and program
verification, for example), into ... well, I don't know what it does
to them, and I don't particularly want to find out.

If I am ever tempted to join the dark side, which I very much doubt,
please remind me of this email.


Incidentally, when browsing through Abadi's papers at
<http://users.soe.ucsc.edu/~abadi/allpapers.html#jsds>, I came across
this one:

  Authentication in the Taos Operating System
  [with Edward Wobber, Michael Burrows, and Butler Lampson]
        ^^^^^^^^^^^^^
  ACM Transactions on Computer Systems 12, 1 (February 1994), 3-32.
  Also appeared as SRC Research Report 117.
  <http://users.soe.ucsc.edu/~abadi/Papers/AuthPaper-TOCS.ps>

Notice in section 3.1 (Authenticating messages):

  PROCEDURE Receive(): (Prin, Msg);

Yep, that's right: two of the authors previously designed a system
that solved this problem the straightforward way. Something about
Microsoft really does warp your mind.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com