[OLPC Security] Bitfrost vs. Rainbow

[Mark Seaborn]

Michael Stone <michael at laptop.org> wrote:

> On Tue, Apr 01, 2008 at 07:50:52PM +0100, Mark Seaborn wrote:
> > Michael Stone <michael at laptop.org> wrote:
> > 
> > >   [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


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

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

>   4) keep reading until I understand the DnD and clipboard protocols
>      clearly enough to evaluate them.
> 
> > 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.

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