Michael Stone <[EMAIL PROTECTED]> wrote: > On Tue, Apr 01, 2008 at 07:50:52PM +0100, Mark Seaborn wrote: > > Michael Stone <[EMAIL PROTECTED]> 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 _______________________________________________ Security mailing list [email protected] http://lists.laptop.org/listinfo/security
