Discussion:
[Plash] Re: X11 proxy related questions
Mark Seaborn
2008-06-08 10:39:46 UTC
Permalink
Hi Mark,
I've recently been researching X11 security in order to write a simple wrapper
that would run X applications (e.g., mostly complex network clients such as
firefox) as an unprivileged user with an untrusted X authorization cookie.
This doesn't work nearly as well as I would like it to. Some applications
crash (e.g., firefox with adobe's flash plugin), and I can't get selections to
work between trusted and untrusted applications (e.g., firefox and a Vim
session), despite tweaking with the security policy for the (legacy) SECURITY
extension.
When I found your wiki notes on X11 security I realized you've probably done
as much in-depth research on this problem as anyone else I have come across.
Your approach is very interesting, and seems to be the most practical way to
achieve seamless yet safe integration between X11 applications at different
privilege levels. The XSELinux approach is a bit overkill for my purposes (I
don't really like the complexity of SELinux) and I haven't yet looked closely
enough at xtsol.
Anyhow, I noticed the last commits to the X11 proxy directory happened around
three months ago, and the wiki page seems to indicate the work is at a pretty
early stage.
1) What is the status of the X11 proxy you are developing? Do you have an
estimate to how long before it is usable?
As an X11 message encoding/decoding library it does a lot, but as an
X11 security proxy it doesn't. It implements some special-case
restrictions such as blocking grabs, but it does not yet implement the
general-case restriction of checking X resource IDs. Making it check
resource IDs will slow it down a lot and it may be necessary to
compile these checks to C to make the proxy usable.

I have since found a tool which should be able to provide most of the
X security requirements very quickly: Xpra. It takes quite a
different approach to my X proxy. It runs applications under a
separate X server (Xvfb). It forwards window contents to the real X
server, and forwards keyboard and mouse input and window positions in
the other direction to the Xvfb server. It was not originally
intended a security tool, but as an X equivalent of "screen".
See <http://partiwm.org> and
<http://lists.partiwm.org/pipermail/parti-discuss/2008-April/000014.html>.

I am not actively working on the X proxy, so I can't say when it will
be usable. I will probably try improving Xpra first.

What security properties are you interested in? Preventing input
injection, for example, is much easier than preventing keyboard
snooping. Preventing denial of service is hard. You might want to
stop applications from stealing the input focus, for example, which
really requires window mangaer support; it can't easily be done by
Xpra or an X proxy on its own.
2) When the X11 proxy is functional, would it be possible to use it
independently of plash?
Yes. In fact I haven't used it with Plash yet.
3) Will secure selections between trusted and untrusted applications be
possible?
I believe it will be possible to forward the X selection between
trusted and sandboxed applications with the X proxy or Xpra. x2x and
Synergy already do this.

The harder part is what it might mean to do that securely. There are
some notes on the wiki about that:
<http://plash.beasts.org/wiki/TrustedPathButtons>
and a thread here:
<http://lists.laptop.org/pipermail/security/2008-April/000391.html>.
In brief, doing copy and paste via the keyboard shortcuts Ctrl-C and
Ctrl-V can be made secure without changing X applications, but making
Copy and Paste menu items secure will require modifying applications.
4) Do you know of a workaround that will enable copy and paste between two
unmodified X11 clients one of which is running as trusted and one which
isn't?
With the X Security extension? I don't know. There is probably no
workaround in this context because the selection protocol requires
writing to properties on another client's window.
5) I can configure the legacy SECURITY SecurityPolicy to allow access
to cut buffers so I'm thinking maybe there might be a way (e.g.,
LD_PRELOAD?) to convert selections to cut buffers. Do you think that
might work?
It seems unlikely. I don't think cut buffers are used much, and they
are fairly different from selections.

Cheers,
Mark
Timo Juhani Lindfors
2008-06-08 11:05:09 UTC
Permalink
Hi,
Post by Mark Seaborn
I have since found a tool which should be able to provide most of the
X security requirements very quickly: Xpra. It takes quite a
different approach to my X proxy. It runs applications under a
separate X server (Xvfb). It forwards window contents to the real X
server, and forwards keyboard and mouse input and window positions in
the other direction to the Xvfb server. It was not originally
intended a security tool, but as an X equivalent of "screen".
See <http://partiwm.org> and
<http://lists.partiwm.org/pipermail/parti-discuss/2008-April/000014.html>.
Sounds interesting. I have been using VNC (which much like Xvfb) to
interact with "questionable" processes in the past. I read the
description of Xpra but I'm not quite sure how it differs from my
current situation. Does it really just copy bitmap from Xvfb to my
real X display?

best regards,
Timo Lindfors
Mark Seaborn
2008-06-08 19:59:06 UTC
Permalink
Post by Timo Juhani Lindfors
Sounds interesting. I have been using VNC (which much like Xvfb) to
interact with "questionable" processes in the past. I read the
description of Xpra but I'm not quite sure how it differs from my
current situation.
Liraz
2008-06-10 16:12:19 UTC
Permalink
Hi Mark,
Post by Mark Seaborn
I have since found a tool which should be able to provide most of the
X security requirements very quickly: Xpra. It takes quite a
different approach to my X proxy. It runs applications under a
separate X server (Xvfb). It forwards window contents to the real X
server, and forwards keyboard and mouse input and window positions in
the other direction to the Xvfb server. It was not originally
intended a security tool, but as an X equivalent of "screen".
See <http://partiwm.org> and
<http://lists.partiwm.org/pipermail/parti-discuss/2008-April/000014.html>.
I am not actively working on the X proxy, so I can't say when it will
be usable. I will probably try improving Xpra first.
Xpra looks very interesting. I didn't realize it could be used for this purpose
when I first came across it. Thanks for the reference!
Post by Mark Seaborn
What security properties are you interested in? Preventing input
injection, for example, is much easier than preventing keyboard
snooping. Preventing denial of service is hard. You might want to
stop applications from stealing the input focus, for example, which
really requires window mangaer support; it can't easily be done by
Xpra or an X proxy on its own.
I don't really care about preventing denial of service, but I do care about
keyboard snooping which could reveal confidential data and also about allowing
an untrusted application (e.g., firefox) to inject events into arbitrary windows
on my desktop.

Stealing input focus is a borderline concern as I believe it would be harder to
exploit in practice.
Post by Mark Seaborn
3) Will secure selections between trusted and untrusted applications be
possible?
I believe it will be possible to forward the X selection between
trusted and sandboxed applications with the X proxy or Xpra. x2x and
Synergy already do this.
Yes, I've used x2x to forward X selections between a trusted X server and an
untrusted nested X server. I'll have to experiment to see how well this works
with Xpra/Xvfb.
Post by Mark Seaborn
The harder part is what it might mean to do that securely. There are
<http://plash.beasts.org/wiki/TrustedPathButtons>
<http://lists.laptop.org/pipermail/security/2008-April/000391.html>.
In brief, doing copy and paste via the keyboard shortcuts Ctrl-C and
Ctrl-V can be made secure without changing X applications, but making
Copy and Paste menu items secure will require modifying applications.
Good idea. I've read the links and I understand the principles, but does an
implementation already exist that I could try out?
Mark Seaborn
2008-06-22 09:23:49 UTC
Permalink
Post by Liraz
Post by Mark Seaborn
What security properties are you interested in? Preventing input
injection, for example, is much easier than preventing keyboard
snooping. Preventing denial of service is hard. You might want to
stop applications from stealing the input focus, for example, which
really requires window mangaer support; it can't easily be done by
Xpra or an X proxy on its own.
I don't really care about preventing denial of service, but I do
care about keyboard snooping which could reveal confidential data
and also about allowing an untrusted application (e.g., firefox) to
inject events into arbitrary windows on my desktop.
Xpra should block keyboard snooping and input injection.
Post by Liraz
Stealing input focus is a borderline concern as I believe it would
be harder to exploit in practice.
Yes, I agree it would be harder to exploit.

Stealing the input focus allows keyboard input to be stolen, but it is
different from other kinds of keyboard snooping in that the input does
not go to the original application, so the user should (eventually)
notice the difference. If a malicious X client opened small top-level
window, this new window might not be very noticeable. If the user
happens to be entering a password, the malicious client could capture
it. The client would probably not have any way to tell when the user
is about to enter a password though, so the risk may be small. Even
so, it could just get lucky.
Post by Liraz
Post by Mark Seaborn
The harder part is what it might mean to do that securely. There are
<http://plash.beasts.org/wiki/TrustedPathButtons>
<http://lists.laptop.org/pipermail/security/2008-April/000391.html>.
In brief, doing copy and paste via the keyboard shortcuts Ctrl-C and
Ctrl-V can be made secure without changing X applications, but making
Copy and Paste menu items secure will require modifying applications.
Good idea. I've read the links and I understand the principles, but does an
implementation already exist that I could try out?
There weren't any such trusted-path clipboard forwarders for X when
you asked the question (as far as I am aware), but since you asked, I
have written one and hooked it up to Xpra. :-)

To try it, check out the following:

svn checkout svn://svn.gna.org/svn/plash/scratch/x11-proxy

git clone http://plash.beasts.org/git/xpra.git

Follow the instruction in Xpra's README.xpra to install the
dependencies and build it, with the extra step that x11-proxy must be
added to PYTHONPATH. I have only hooked up the clipboard forwarder to
the "xpra standalone" subcommand that I added in this branch, which
does not provide the persistence functionality (the P in Xpra).

So to run an application through Xpra, do something like:

export PYTHONPATH=$(pwd)/install/lib/python:../x11-proxy:$PYTHONPATH
export PATH=$(pwd)/install/bin:$PATH
xpra standalone COMMAND ARGS...

I tested this briefly with Leafpad (a very simple Notepad-like text
editor). You can verify that Xpra is not forwarding the clipboard
unconditionally from the way the Edit -> Copy/Paste menu items don't
work unless the clipboard has been forwarded by pressing Ctrl-X,
Ctrl-C or Ctrl-V.

The forwarder is not complete. It does not yet properly handle
different selection format types (called "targets" in the terminology
of the selection protocol). I have put some notes on
http://plash.beasts.org/wiki/X11Selections.

Cheers,
Mark

Loading...