Create a *real* top level window

Carsten Haitzler (The Rasterman) raster at rasterman.com
Thu Sep 23 17:38:10 PDT 2010


On Thu, 23 Sep 2010 18:19:16 +0300 Timo Juhani Lindfors <timo.lindfors at iki.fi>
said:

> Carsten Haitzler (The Rasterman) <raster at rasterman.com> writes:
> > luck. in the x11 world access gets flattened. the user is pretty much king.
> 
> That's the impression I've unfortunately got too.
> 
> > my suggestions is to stand back and totally rethink what you are
> > trying to do.
> 
> I have several different use cases but mainly I'm interested in
> improving the common usage pattern: users run web browser and sudo
> under the same X server. If an attacker can run arbitrary code due to
> a bug in the web browser they can easily wait for the user to invoke
> sudo and then escalate to root.
> 
> As a pet project I've been planning a sudo wrapper that provides
> trusted path for acknowledging each command. You can read the details
> at
> 
> http://lindi.iki.fi/lindi/darcs/sido/README
> 
> but the project is currently stuck due to challenges with X.
> 
> > logged in user is king. you'd have to modify the xserver itself to have
> > such a separation and provide a back-channel that can only be accessed by
> > root to implement what you want. reality otherwise is that any x client can
> > kill off
> 
> I think I have explored most of these options:
> 
> 1) as a "back-channel" I use
> /dev/input/by-path/platform-i8042-serio-0-event-kbd for input and a
> separate virtual console for output. The drawback here is that drivers
> are buggy and can crash the system on vt switch..
> 
> 2) normal users could run all their programs under vnc4server and when
> they login I would just run fullscreen xvnc4viewer as a trusted
> user. This is easy but causes extra slowdown. I did not research this
> further since I wanted a solution that'd be usable by normal desktop
> users.
> 
> 3) I looked at XACE. It looks that it might be possible to write an
> extension that'd give special powers to clients that have
> authenticated using a specific magic cookie. I am not sure if this is true.
> 
> 4) I have looked at selinux extension. It looks like it could work but
> the papers mention that a modified twm is needed, I have not found the
> source of that yet and I am not familiar with selinux:
> 
> "Here's a screen shot of a hacked twm that displays this property in
> place of the usual window title:
> http://people.freedesktop.org/~ewalsh/twm-demo.png"
> 
> -- http://www.nsa.gov/research/selinux/list-archive/0611/thread_body83.shtml
> 
> 5) Finally I have looked at KMS in the hope that it could provide a
> "graphical back-channel" but have not succeeded yet here either.

hmm well i think possibly the best bet is to flip it upside down here. run
"untrusted" clients - like your borwser example, through some mechanism like a
nested xserver (rootless). xpra may help here. it will give a performance hit
for the untrusted client. it will also heavily limit how it can interact with
the rest of the users "trusted" desktop, but this is just what you want. you
can pretty much lock down all access at this server level and only allow in and
out what is deemed "harmless". browser can run as another untrusted UID that
connects only to this nested x, and the nested x then is your barrier. make
sure it has no holes as it has full x access to the trusted display.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com




More information about the xorg mailing list