On Sat, 21 Mar 2015 14:14:22 -0700 luke...@onemodel.org wrote: > On 03/16/15 19:38, Jean-Philippe Ouellet wrote: > > On Sun, Mar 15, 2015 at 07:12:23PM -0400, Ted Unangst wrote: > >> luke...@onemodel.org wrote: > >>> The goal: I'd like to run multiple simultaneous X sessions and switch > >>> among them with Ctrl-Alt-F8, Ctrl-Alt-F9, etc, each one as a different > >>> user (separation of privileges, like general browsing vs. admin & > >>> programming, vs. banking, etc, so that if one is compromised by a > >>> browser flaw etc, the other user accounts are unaffected. > >> I would probably start with Xnest here. > > I've had better luck with a slightly hacked up Xephyr for this purpose. > > > > Just be aware that screen locking at the top level won't work while nested > > sessions grabbed exclusive focus (unless you patch it to work differently), > > and window resizing can be annoying at times. > > > > Be sure to actually isolate the different X server processes across > > different > > users and such and preferably chroot them and tell pf to block everything > > for > > those users. > > > > It's annoying and probably doesn't really gain you much anyway. > > That sounds doable, but too easy for me to make a mistake that > invalidates it, and I don't know whether in that strategy a compromised > app (such as a browser) could watch keystrokes on another app. >
while i am no X guru by any means, i am pretty sure that the X11 SECURITY extension prevents that. (that is at least what i take away from the section for -X in ssh(1)). > (This other thread is also interesting in this light (from ~2 days > ago): "isolating untrusted programs in ssh chroot jails".) that's mine. basically i detail how to do most of what Mssr. Ouellet mentioned above. > > So, I was going to try doing as Miod kindly suggested in another part > of this thread: > > On 03/15/15 04:15, Miod Vallat wrote: > >> If you run another X server instance, it will use the seventh virtual > >> console (ctrl-alt-F7). But I am not sure drm-enabled X servers can run > >> multiple instances. > > Thanks. Is there a way to turn off drm, such as via a sysctl > > setting for kern.malloc.kmemstat.DRM, or somehow forcing it to use a > > different (known stable) driver? Or, if not, anything else I can > > try except non-drm video hardware? > > ...until I stumbled on this which looks the easiest/safest so far: > > List: openbsd-misc > > Subject: Re: Almost offtopic question to the "Improving Browser > > > Security" question > > From: Stuart Henderson <stu () spacehopper ! org> > > Date: 2015-03-04 8:37:03 > > Message-ID: slrnmfdh1f.8gs.stu () naiad ! spacehopper ! org > > > > On 2015-03-03, someone <thisistheone8...@gmail.com> wrote: > > > Wow, copying the .Xauthority to the "separated" user worked! > > > But I'm still thinking that the "separated" user can give out the > > > command: > > > xinput test 6 > > > and can see what anyone types in via X. > > See xauth(1) about generating an untrusted auth token. If you're > > feeling lazy, enabling ssh X forwarding and using ssh -X > > user@localhost might be easier, but will be slower. > (http://marc.info/?l=openbsd-misc&m=142545841513214&w=2 > ...which started here (also useful): > http://undeadly.org/cgi?action=article&sid=20150303075848 ) > > > So, if I use xauth after reading the manpage carefully, or use ssh -X > from one localhost user to another, and launch a bunch of apps as > different users all in the same X server, what are the risks of > compromise between accounts? > > Thanks to all who've commented: this has been educational & useful. > > -Luke A Call > there is probably about as little chance of compromise as is possible. the only real privilege separation on unix is having different users, and restricting them as much as possible (like with chroot). if you are running a command as another user, ie: ssh -X pdf@localhost xpdf file.pdf then the only way the program has to interact with your display is thru an ssh tunnel which acts as a filter. so in this case xpdf will write to the DISPLAY given to it from ssh, which is a tunnel created by ssh which restricts the commands that can be sent along that tunnel to the real display. it's not possible to isolate an account completely from the system unless it is chroot(8)ed. that way that user will not have access to anything else in the filesystem. if you read my notes though, i note it is not possible for all programs to be locked up so. you can skip the chroot part of my notes, near the end i explain using Xephyr. Xephyr is probably not the most trustworthy, but it's a choice between writing to it, or to the main server. the only thing i don't really get into in my notes is what Mssr. Ouellet mentions regarding using pf to block the user. this obviously is not a good idea for a web browser, but for something like xpdf it is. you just need some rules in pf.conf like: block out log pass out log quick on $intif proto tcp user { browse, 1000 } pass out log quick on $intif proto udp user { browse, 1000 } which blocks all outgoing traffic, except what is allowed to 'pass'. in this case all outgoing traffic is blocked except for users 'browse' and the one with uid 1000. even root is blocked with the above config. other than that, having a physically separate machine is probably the only thing you can do to make it more secure. i wrote some scripts to do most of this automatically, they were in the second post in my thread you mentioned above. so it is easy to set up. the scripts create the users, groups, jail, install the packages, etc. the only thing they don't do is launch Xephyr or modify pf.conf (i have another script deals with Xephyr). the best way to see if you can chroot something is to just run those scripts, and try to run the program after it is installed in the jail. all of this is already detailed in that other thread though, so i'll just leave it at that.
