[OLPC Security] Bitfrost vs. Rainbow

[Toby Murray]

Hi,

I'm writing to enquire about the differences (if any) between the
Bitfrost ideals and the Rainbow implementation.

In particular, the original Bitfrost documentation (e.g. [1]) suggests
that it would be implemented using the VServer to control filesystem
visibility etc.

However, a quick look at relevant Rainbow docs (specifically [2])
indicate that Rainbow might be implemented using only the standard Linux
DAC mechanisms -- essentially, very similar to the Polaris design[3].

Some more specific questions:

- Does Rainbow use chroot?
- If so, how does its filesystem protections go beyond what Plash [4]
offers?
- In particular, Plash has some (or is close to providing) support for
copy-on-write access, which is hinted at in [2].

Any info would be great.

Finally, were one interested in hacking on Rainbow, what is an ideal
development environment for doing so? (Particularly for someone without
access to an XO).

Many thanks,

and cheers to all of those involved here. OLPC, and its security
model/architecture, are nothing if not the most successful vehicle by
which "least authority" has been sold to an otherwise apathetic
audience. Kudos.

Toby

[1] http://cups.cs.cmu.edu/soups/2007/proceedings/p132_krstic.pdf
[2]
http://dev.laptop.org/git?p=users/mstone/security;a=blob;f=rainbow.txt;hb=HEAD
[3] http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html
[4] http://plash.beasts.org/wiki/

[Jameson "Chema" Quinn]

A good place to start: http://wiki.laptop.org/go/Bitfrost#Current_Status

In particular, the Rainbow implementation has no chroot/ vserver that I know
of, it is all pid's and file permissions.

On Mon, Mar 31, 2008 at 7:12 PM, Toby Murray <toby.murray at comlab.ox.ac.uk>

Post by Toby Murray
Hi,
I'm writing to enquire about the differences (if any) between the
Bitfrost ideals and the Rainbow implementation.
In particular, the original Bitfrost documentation (e.g. [1]) suggests
that it would be implemented using the VServer to control filesystem
visibility etc.
However, a quick look at relevant Rainbow docs (specifically [2])
indicate that Rainbow might be implemented using only the standard Linux
DAC mechanisms -- essentially, very similar to the Polaris design[3].
- Does Rainbow use chroot?
- If so, how does its filesystem protections go beyond what Plash [4]
offers?
- In particular, Plash has some (or is close to providing) support for
copy-on-write access, which is hinted at in [2].
Any info would be great.
Finally, were one interested in hacking on Rainbow, what is an ideal
development environment for doing so? (Particularly for someone without
access to an XO).
Many thanks,
and cheers to all of those involved here. OLPC, and its security
model/architecture, are nothing if not the most successful vehicle by
which "least authority" has been sold to an otherwise apathetic
audience. Kudos.
Toby
[1] http://cups.cs.cmu.edu/soups/2007/proceedings/p132_krstic.pdf
[2]
http://dev.laptop.org/git?p=users/mstone/security;a=blob;f=rainbow.txt;hb=HEAD
[3] http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html
[4] http://plash.beasts.org/wiki/
_______________________________________________
Security mailing list
Security at lists.laptop.org
http://lists.laptop.org/listinfo/security

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080331/b5b0a5ef/attachment.htm

[Michael Stone]

Toby,

First, thanks for giving me such exciting reading material this evening.
I've run into Polaris before (many moons ago) but was not previously
familiar with the work of the Plash authors. You're certainly correct
that Rainbow bears the mark of similar design imperatives!

Post by Toby Murray
I'm writing to enquire about the differences (if any) between the
Bitfrost ideals and the Rainbow implementation.

Numerous; primarily caused by fear, uncertainty, and doubt about how to
proceed beyond the well established bounds of Unix discretionary access
control into the uncharted waters of network and X isolation. Jameson
pointed you to the right URL for the short summary; in response, you
should pose more specific questions for me to attempt to answer. (Or you
should read the source code, which is brief, mostly to the point, and
somewhat documented (for older versions) [1]).

[1]: http://wiki.laptop.org/go/Taste_the_Rainbow

Post by Toby Murray
In particular, the original Bitfrost documentation (e.g. [1]) suggests
that it would be implemented using the VServer to control filesystem
visibility etc.

We tried it last summer and discovered that the social expenses of the
route outweighed the gain. Then I took a hard look at the problem and
reached the conclusion that a "cheapskate" solution existed. Finally, I
documented the skeleton of that solution in the "rainbow.txt" link that
you cited.

Post by Toby Murray
However, a quick look at relevant Rainbow docs (specifically [2])
indicate that Rainbow might be implemented using only the standard Linux
DAC mechanisms -- essentially, very similar to the Polaris design[3].

Correct to date, though we've basically reached the limits of the
existing DAC framework. Clever (or stupid, depending on your
perspective) hacks now seem to be required. For network isolation, I'm
currently intending to go forward with compartmentalized "network" and
"not-network" processes based on Dan Bernstein's sys_disablenetwork()
idea [2].

[2]: http://cr.yp.to/unix/disablenetwork.html

For X, I'm still at the research stage, currently investigating both
XACE [3] and an off-the-cuff idea involving per-uid Xephyrs (or
similar tomfoolery).

(I've spent some time thinking hard about approaches based on selinux
and I'm simply unable to convince myself that we can afford the
cognitive burden of writing bespoke policy which can only be debugged by
SElinux hackers. Systems based on Unix DAC seem to avoid this problem
because the tools for debugging the DAC are well understood by a much
larger body of people and because the rules governing context
transitions are mostly static and mostly local (as opposed to global and
dynamic in SElinux).)

Post by Toby Murray
- Does Rainbow use chroot?

No. The vserver implementation used chroot+read-only bind-mounts but it
greatly increased the complexity of the activity debugging process in
exchange for little obvious gain (in OLPC's default environment). I'm
happy to revisit this decision in the future if we discover
security-relevant discrepancies between my assumptions about how the XOs
will be used and reality.

Post by Toby Murray
- If so, how does its filesystem protections go beyond what Plash [4]
offers?

In its present form, Rainbow appears to be quite comparable to Plash;
perhaps a bit weaker, and likely less well tested.

Post by Toby Murray
- In particular, Plash has some (or is close to providing) support for
copy-on-write access, which is hinted at in [2].

We implemented CoW filesystem access based on VServer's CoW
link-breaking primitive but concluded on the basis of the prototype
that, at the time, we were unable to afford the required system
maintenance. (There was a particularly bad interaction between a race
condition in VServer's implementation of CoW link-breaking and the JFFS2
garbage collector which was eating filesystems during a release week.)

Post by Toby Murray
Any info would be great.

Ask more specifically and ye shall receive. :)

Post by Toby Murray
Finally, were one interested in hacking on Rainbow, what is an ideal
development environment for doing so? (Particularly for someone without
access to an XO).

Well, there are a couple of answers, depending on your tastes. First,
I'm extremely interested in cleaning Rainbow up to the point where it's
usable outside of OLPC's exact filesystem layout. If you're interested
in the same, then we might be able to work very profitably on getting it
running in whatever environment is most pleasing to you.

Next, there are several emulation environments. Marcus Leech is someone
good to talk to here about the trials and tribulations of OLPC's support
for emulated environments. (Again, it's an area in which we know we can
do better and in which we desire to do better. Outside folks who depend
on it and who make their voices heard when things break are extremely
valuable for making the whole system easier to deal with.)

Finally, you can request a machine through the developer program [2].

[2]: http://wiki.laptop.org/go/Developer_program

Thanks for contacting us!

Michael

P.S. - It sounds like our goals are closely aligned with some of the
goals of the Plash project - also, OLPC has no desire to maintain
bespoke security software just for kicks. Can you suggest some an
approachable Plash developer (or mailing list?) to suggest that we
explore ways to further our mutual aims in concert?

[Mark Seaborn]

Post by Michael Stone

Post by Toby Murray
However, a quick look at relevant Rainbow docs (specifically [2])
indicate that Rainbow might be implemented using only the standard Linux
DAC mechanisms -- essentially, very similar to the Polaris design[3].

Correct to date, though we've basically reached the limits of the
existing DAC framework. Clever (or stupid, depending on your
perspective) hacks now seem to be required. For network isolation, I'm
currently intending to go forward with compartmentalized "network" and
"not-network" processes based on Dan Bernstein's sys_disablenetwork()
idea [2].
[2]: http://cr.yp.to/unix/disablenetwork.html

That is the approach I would like to take with Plash for limiting
network access. In general, I would like to be able to disable most
system calls, leaving only those that deal purely with file
descriptors (as listed on http://plash.beasts.org/wiki/PtraceJail).
One way to do that would be to use ptrace(), possibly with Jeff Dike's
PTRACE_SYSCALL_MASK patch.

Post by Michael Stone
For X, I'm still at the research stage, currently investigating both
XACE [3] and an off-the-cuff idea involving per-uid Xephyrs (or
similar tomfoolery).

I have been investigating this area and there are some notes on the
Plash wiki:
http://plash.beasts.org/wiki/X11Security
http://plash.beasts.org/wiki/X11SecurityRequirements

I expect that Sugar's X security requirements would be easier to meet
than mine, since Sugar's GUI is much simpler, lacking a conventional
window manager with overlapping windows.

What are you considering doing with Xephyr?

I have considered adapting Xnest to support a rootless mode (similar
to Cygwin X's rootless mode) in which Xnest's top-level windows
co-exist among the parent X server's top-level windows, instead of
appearing inside a nested window. It did not appear to be practical
because Xnest re-uses all of a normal X server's keyboard and mouse
input processing, including grab processing.

I have investigated XACE and decided against using it for reasons that
are partly architectural and partly practical. The idea of filtering
X requests does not fit with Plash's aim of having a capability
architecture. Since XACE is just a set of internal server hooks, it
requires a lot to be done on the server side. I am not convinced that
my requirements for handling top-level windows and proxying access to
the X clipboard can be achieved using something like XACE without
putting a lot of complexity into the X server.

I have been experimenting with writing a security-enforcing X proxy.
I've got an incomplete prototype written in Python:
http://plash.beasts.org/wiki/X11ProxySpike

Post by Michael Stone
P.S. - It sounds like our goals are closely aligned with some of the
goals of the Plash project - also, OLPC has no desire to maintain
bespoke security software just for kicks. Can you suggest some an
approachable Plash developer (or mailing list?) to suggest that we
explore ways to further our mutual aims in concert?

I'm the main Plash developer. I read this list but you're welcome to
post on Plash's mailing list
(http://lists.nongnu.org/mailman/listinfo/plash) or cross-post.

I've been on this list since Bitfrost was announced. It's good to
hear some more details about the planned implementation. I don't
think I knew before today that the implementation is called Rainbow!

Regards,
Mark

[Michael Stone]

Mark,

First, thanks very much for your commentary; I apologize that I was
unable to reply until now.

Post by Mark Seaborn

Post by Michael Stone
[2]: http://cr.yp.to/unix/disablenetwork.html

That is the approach I would like to take with Plash for limiting
network access.

I took a fairly direct route toward this goal: namely, I wrote a
'long sys_disablenetwork(void)' syscall and an LSM to implement it [1].
(I chose to use an LSM because OLPC is not presently using any LSMs and
because it requires no changes to the kernel's task_struct.)

[1]: http://dev.laptop.org/git?p=users/mstone/olpc-2.6;a=commit;h=c05cc7eadcee3d9450c1eb6a41ef9c932f9aad53

I have not yet made any attempts to push this work into use, largely due
to my unfamiliarity with the overall kernel development process and the
limited time that I'm able to devote to the problem.

Post by Mark Seaborn

Post by Michael Stone
For X, I'm still at the research stage, currently investigating both
XACE [3] and an off-the-cuff idea involving per-uid Xephyrs (or
similar tomfoolery).

I have been investigating this area and there are some notes on the
http://plash.beasts.org/wiki/X11Security
http://plash.beasts.org/wiki/X11SecurityRequirements
I expect that Sugar's X security requirements would be easier to meet
than mine, since Sugar's GUI is much simpler, lacking a conventional
window manager with overlapping windows.

I had a nice chat with an X developer last night (Ajax) about our
security goals. We reached the tentative conclusion that event synthesis
and input injection attacks are much more problematic for OLPC than are
snooping attacks. At this point, my goals are to

1) make sure Xtest is disabled.
2) examine and control XSendEvent().
3) disable or rate-limit changes to the keyboard map in order to
prevent keypress spoofing attacks against the user.
4) keep reading until I understand the DnD and clipboard protocols
clearly enough to evaluate them.

Post by Mark Seaborn
What are you considering doing with Xephyr?

Basically, I was curious whether we could provide separate X servers for
each activity and then fix up DnD and the clipboard afterward. I asked Jim
Gettys to think about it and he replied that he presently thinks it will
be easier to write an appropriate XACE module. (DnD, clipboard, hardware
acceleration, and the Input layer were the major concerns.)

Post by Mark Seaborn
I am not convinced that my requirements for handling top-level windows
and proxying access to the X clipboard can be achieved using something
like XACE without putting a lot of complexity into the X server.

Could you say more about your goals for the clipboard?

Thanks,

Michael

[Mark Seaborn]

Post by Michael Stone

Post by Mark Seaborn

Post by Michael Stone
[2]: http://cr.yp.to/unix/disablenetwork.html

That is the approach I would like to take with Plash for limiting
network access.

I took a fairly direct route toward this goal: namely, I wrote a
'long sys_disablenetwork(void)' syscall and an LSM to implement it [1].
(I chose to use an LSM because OLPC is not presently using any LSMs and
because it requires no changes to the kernel's task_struct.)

It looks like that syscall can be used by a normal user. Is that
correct?

Having looked at the patch, I notice it disables sendmsg() (although
not recvmsg()?). That would be a pity since it prevents processes
from using FDs they have received.

By the way, allowing creation of AF_UNIX sockets is not quite safe any
more since the so-called "abstract namespace" for domain sockets [1]
was introduced, because it is a global namespace. I have not found
any explanation of why this was introduced.

[1] http://plash.beasts.org/wiki/DomainSocketAbstractNamespace

Post by Michael Stone
I had a nice chat with an X developer last night (Ajax) about our
security goals. We reached the tentative conclusion that event synthesis
and input injection attacks are much more problematic for OLPC than are
snooping attacks.

Why is input injection worse than snooping?

Post by Michael Stone
At this point, my goals are to
1) make sure Xtest is disabled.
2) examine and control XSendEvent().
3) disable or rate-limit changes to the keyboard map in order to
prevent keypress spoofing attacks against the user.

Surely normal applications should not get the authority to change the
keyboard mapping?

Post by Michael Stone
4) keep reading until I understand the DnD and clipboard protocols
clearly enough to evaluate them.

Post by Mark Seaborn
What are you considering doing with Xephyr?

Basically, I was curious whether we could provide separate X servers for
each activity and then fix up DnD and the clipboard afterward. I asked Jim
Gettys to think about it and he replied that he presently thinks it will
be easier to write an appropriate XACE module. (DnD, clipboard, hardware
acceleration, and the Input layer were the major concerns.)

DnD: does Sugar have drag-and-drop between applications?

Clipboard: if Sugar apps did clipboard access entirely via, say, D-Bus
instead of X you could disable X clipboard access. But maybe it is
simpler to go via X.

Post by Michael Stone

Post by Mark Seaborn
I am not convinced that my requirements for handling top-level windows
and proxying access to the X clipboard can be achieved using something
like XACE without putting a lot of complexity into the X server.

Could you say more about your goals for the clipboard?

Just as sandboxed applications get read or write access to the user's
files via a trusted-path file chooser (the file powerbox), they should
only get read or write access to the clipboard via a trusted-path user
interface. Applications should only be able to read from (paste) or
write (cut/copy) to the clipboard after an explicit action from the
user, such as a key press or a mouse click, and the user needs to be
able to tell what consequence their action will have.

In CapDesk, I believe the clipboard interface is a toolbar,
implemented by the user's TCB, containing Cut/Copy/Paste buttons. As
far as I know, CapDesk was the first system to implement or describe
this kind of trusted-path clipboard.

In the EROS Trusted Window System (EWS), if I remember correctly, the
application can nominate hotspots that, when clicked, will perform
Copy or Paste. The window system changes the pointer shape over those
hotspots, but aside from that they are not visually identifiable.

A normal X application does not expect to be told when to copy or
paste as such. However, the system could assume that Ctrl-C means
Copy, which grants the application the authority to write to the
clipboard, and Ctrl-V means Paste, which grants the application the
authority to read from the clipboard. In both cases the authority is
revoked on the next Copy action.

The X clipboard protocol allows for some content type negotiation.
CapDesk and EWS propose to allow content type negotiation in such a
way that communication is one-way only: the clipboard reader cannot
send data to the clipboard writer. I think CapDesk might even
implement that: The clipboard writer supplies a function and the
system checks that the function references no mutable objects.

That feature would be nice to have, but a trusted-path clipboard would
be an improvement over normal clipboard mechanisms even if introduced
a two-way channel upon Paste.

In principle implementation would be a case of allowing two X clients
to communicate when one holds write access and the other holds read
access. A client can do SetSelectionOwner or ConvertSelection but
these requests will not always succeed.

Note that I am talking about X's CLIPBOARD. The conventional
interface for X's SELECTION is not securable: pasting with the middle
button might be securable, but copying just by selecting text is not.

Regards,
Mark

[Karl O. Pinc]

Post by Mark Seaborn

Post by Michael Stone
Could you say more about your goals for the clipboard?

Just as sandboxed applications get read or write access to the user's
files via a trusted-path file chooser (the file powerbox), they should
only get read or write access to the clipboard via a trusted-path user
interface. Applications should only be able to read from (paste) or
write (cut/copy) to the clipboard after an explicit action from the
user, such as a key press or a mouse click, and the user needs to be
able to tell what consequence their action will have.
Note that I am talking about X's CLIPBOARD. The conventional
interface for X's SELECTION is not securable: pasting with the middle
button might be securable, but copying just by selecting text is not.

I don't understand the last sentence.
Why is selecting text (or using the middle mouse button to paste)
any less of an "explicit action" than Ctrl-C (or Ctrl-V)?


Karl <kop at meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

[Mark Seaborn]

Post by Karl O. Pinc

Post by Mark Seaborn

Post by Michael Stone
Could you say more about your goals for the clipboard?

Just as sandboxed applications get read or write access to the user's
files via a trusted-path file chooser (the file powerbox), they should
only get read or write access to the clipboard via a trusted-path user
interface. Applications should only be able to read from (paste) or
write (cut/copy) to the clipboard after an explicit action from the
user, such as a key press or a mouse click, and the user needs to be
able to tell what consequence their action will have.
Note that I am talking about X's CLIPBOARD. The conventional
interface for X's SELECTION is not securable: pasting with the middle
button might be securable, but copying just by selecting text is not.

I don't understand the last sentence.
Why is selecting text (or using the middle mouse button to paste)
any less of an "explicit action" than Ctrl-C (or Ctrl-V)?

There are lots of ways text can become selected: by dragging; by
double clicking; by pressing Shift-Left or Shift-Right; or in Emacs,
by pressing Ctrl-Space and then the arrow keys. How would the window
system tell when these actions claim the selection and when they
don't? It could assume that every drag or double click claims the
selection, but that will cause false positives, which have the
consequence that the selection gets overwritten, and how should the
window system distinguish between clicks and drags? If the window
system did not know about Shift-Right causing a selection, that would
cause false negatives, which have the consequence that there is a
selection displayed on screen which is not pastable.

The same problem exists with assuming that Ctrl-C always means Copy,
just to a lesser extent. In the scheme I described before, pressing
Ctrl-C in a terminal window would overwrite the clipboard, even though
it means "send SIGINT" rather than Copy. The scheme could be modified
so that the clipboard is only overwritten after Ctrl-C is pressed
*and* the application claims the clipboard, but that change would make
it less predictable because the owner of the selection would depend on
application behaviour.

Regards,
Mark