Re: running multiple simultaneous X sessions as different users
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
> > Date: 2015-03-04 8:37:03
> > Message-ID: slrnmfdh1f.8gs.stu () naiad ! spacehopper ! org
> >
> > On 2015-03-03, someone 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 }
pa
Re: running multiple simultaneous X sessions as different users
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. (This other thread is also interesting in this light (from ~2 days ago): "isolating untrusted programs in ssh chroot jails".) 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 > Date: 2015-03-04 8:37:03 > Message-ID: slrnmfdh1f.8gs.stu () naiad ! spacehopper ! org > > On 2015-03-03, someone 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
Re: running multiple simultaneous X sessions as different users
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. Oh, hmm, I had forgotten about Xephyr. I like this bit from the man page: The build gets a warning about 'nanosleep'. I think the various '-D' build flags are causing this. I haven't figured as yet how to work round it. It doesn't appear to break anything however. Gives me slight pause that in apparently ten years, nobody has bothered to resolve what appears to be a rather simple issue. I doubt Xnest is actually any better with "Still crashes randomly." but at least random crashes sound like a "hard" problem.
Re: running multiple simultaneous X sessions as different users
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.
Re: running multiple simultaneous X sessions as different users
luke...@onemodel.org wrote: > I'm new to desktop OpenBSD (longtime debian user) and have read in > FAQs, all relevant man pages I could find, and searched the internet > and mailing list archives, and am not sure what I'm doing wrong or have > missed. > > 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.
Re: running multiple simultaneous X sessions as different users
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?
Re: running multiple simultaneous X sessions as different users
> Now I finally (cough) notice those error messages in dmesg.boot. Not > sure how critical they are, if it's referring to missing binary blobs, > and if openbsd has fallen back to acceptable/stable defaults or > something. But where it says "screen 1-5 added", that seems to connect > with 'man wsdisplay' saying that screens can be > configured with either the wsconscfg utility or a (kernel?) > compile-time parameter. I tried running things like "wsconscfg 6" (& > 7, 8), which return 0, but it didn't seem to change the behavior. The kernel will attach WSDISPLAY_DEFAULTSCREENS virtual consoles by default, which is 6 on i386 and amd64 platforms. More virtual consoles (up to WSDISPLAY_MAXSCREEN, which is 12) can be created by using wsconscfg as you did. Your dmesg output will report something like: wsdisplay0: screen 6 added (std, vt100 emulation) Now, for X to find a proper virtual console to run on, it has to find an unused one, i.e. one where no getty(8) runs. This is controlled by /etc/ttys, and in the default congfiguration of six virtual consoles, only the fifth (ctrl-alt-F5) is left unused and available for X. 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. Miod
Re: running multiple simultaneous X sessions as different users
On 03/14/15 15:22, 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 [] Here is the output I get when I have one X session running and I then run "startx -- :1" ... $ startx -- :1 [xauth: file /home/myusername/.serverauth.5199 does not exist] xauth: (stdin):1: [bad display name "myhostname.mydomain-sans-toplevel.org:1" in "add" command] (EE) server terminated with error (1). [Closing log file.] xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error [xauth: (argv):1: bad display name "myhostname.mydomain-sans-toplevel.org:1" in "remove" command] [] Here is the full content of /var/run/dmesg.boot: [] drm: initializing kernel modesetting (RV515 0x1002:0x7145 0x1028:0x2002). radeondrm0: VRAM: 256M 0x - 0x0FFF (128M used) radeondrm0: GTT: 512M 0x1000 - 0x2FFF drm: PCIE GART of 512M enabled (table at 0x0004). error: [drm:pid0:r100_cp_init_microcode] *ERROR* radeon_cp: Failed to load firmware "radeon-r520_cp" error: [drm:pid0:r100_cp_init] *ERROR* Failed to load firmware! error: [drm:pid0:rv515_startup] *ERROR* failed initializing CP (-2). error: [drm:pid0:rv515_init] *ERROR* Disabling GPU acceleration drm: radeon: cp finalized error: [drm:pid0:radeon_bo_unpin] *ERROR* 0xd91c5190 unpin not necessary radeondrm0: 1920x1200 wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0 wsdisplay0: screen 1-5 added (std, vt100 emulation) Now I finally (cough) notice those error messages in dmesg.boot. Not sure how critical they are, if it's referring to missing binary blobs, and if openbsd has fallen back to acceptable/stable defaults or something. But where it says "screen 1-5 added", that seems to connect with 'man wsdisplay' saying that screens can be configured with either the wsconscfg utility or a (kernel?) compile-time parameter. I tried running things like "wsconscfg 6" (& 7, 8), which return 0, but it didn't seem to change the behavior. Is there anything short of customizing my (kernel build with that WSDISPLAY_DEFAULT_SCREENS=N setting? Or, does bootup somehow call wsconscfgN in a way that I can configure for more screens (that I haven't found yet)? Is doing either one of those things known to be safe/stable? And, how does the system know that some of the already-configured screens are for console use, and one (ctrl-alt-f5 at least) for X? Thanks. -Luke
