Re: Don't forget systrace Was: running multiple simultaneous X sessions as different users
On 03/22/15 07:44, Kevin Chadwick wrote: Systrace is also an option but the policy writing could be a little work, the regex support is certainly helpful there. systrace -A is very helpful Excellent info; thanks. (This list has the highest signal/noise ratio among tech lists that come to mind.) For now I'll try ssh -X user, umask 0077 for all users including root (though I learned the hard way you have to relax that before doing pkg_add...), and keep all this other material as reference for when I can do more or want to try things more like systrace, xauth etc (or non-drm video driver etc to get more screens recognized by X). That is, unless I learn that there are still ways for one user to view another's data etc, when I do just that much. Corrections to my thinking are welcomed. (This effort is so impressive. Especially compared to so many other situations where if it seems to work on the surface, even smart people call it good move on. It seems like the worst problems now could be hardware security, which seems very hard, and 3rd-party systems. And general human behavior but we can keep trying there too.) Best regards, Luke
Re: Don't forget systrace Was: running multiple simultaneous X sessions as different users
On Sat, 21 Mar 2015 14:14:22 -0700 luke...@onemodel.org wrote: Thanks to all who've commented: this has been educational useful. Systrace is also an option but the policy writing could be a little work, the regex support is certainly helpful there. systrace -A is very helpful then edit files in .systrace such as removing lib version numbers to prevent upgrades from breaking the policy and adding regex for IP connections systrace -a to enforce. Personally I'd like to use systrace -A with cksum -a sha256 on the updated policy file and gxmessage to warn about previously unseen behaviour but unfortunately I don't think the policy generation has any regex support so every IP connected to will be logged and flag up new behavior and I think the -E logging option will only help in enforcement mode. There used to be a gui mode which I believe Ted removed without any objections but was quite cool and would enforce but ask you upon new system calls but it would very occasionally get stuck during the deny while asking stage and so cause user complaints (here, not on list). chflags sappnd might work too on the policy files making a pretty good yet trouble free HIPS but I haven't tested that yet
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 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-miscm=142545841513214w=2
...which started here (also useful):
http://undeadly.org/cgi?action=articlesid=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,
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 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-miscm=142545841513214w=2 ...which started here (also useful): http://undeadly.org/cgi?action=articlesid=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
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
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/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
running multiple simultaneous X sessions as different users
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. Here is the output I get when I have one X session running as one (non- root) user (which I started with startx since I'm not using xdm or any such, and prefer not to use them), and I then run startx -- :1 as another (non-root) user look like this, in the console of the 2nd user. I have surrounded with [] brackets the lines that ALSO show up when running X successfully as the 1st user (with tiny differences): $ 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] Is it practical to do what I'm trying? Can you tell me what I need to do how I missed it (for future tries at solving my own problems ... :) ? Details: This is OpenBSD 5.6 with updates from the stable CVS branch on (IIRC) 2014-12-27 (that's the latest date in the /usr/src/lib and /usr/X.../lib directories), on an old dell inspiron 9400. The contents of /var/log/Xorg*.log (0 and 1), and output of dmesg and contents of /var/run/dmesg.boot, and xorg.conf respectively are at the end of this message. When this failure happens, there is no content added to an .xsession-errors file. There is an .Xauthority file with a new date. The return code from startx is 1. I generated an /etc/X11/xorg.conf file by running Xorg -configure as root, which didn't fix it. I also tried adding several ServerLayout and matching Screen sections (numbered 1-5 or so) to my xorg.conf file like this, but it didn't help either: ... Section ServerLayout Identifier X.org Configured-thencopied1 Screen 0 Screen1 0 0 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard EndSection ... Section Screen Identifier Screen1 Device Card0 MonitorMonitor0 SubSection Display Viewport 0 0 Depth 1 EndSubSection SubSection Display Viewport 0 0 Depth 4 EndSubSection SubSection Display Viewport 0 0 Depth 8 EndSubSection SubSection Display Viewport 0 0 Depth 15 EndSubSection SubSection Display Viewport 0 0 Depth 16 EndSubSection SubSection Display Viewport 0 0 Depth 24 EndSubSection EndSection I also tried commands like this to be more specific, which didn't help: xinit /etc/X11/xinit/xinitrc -- /usr/X11R6/bin/X :1 -auth /home/lacall/.serverauth.100 I also tried adding this line to sysctl.conf but it didn't help. machdep.allowaperture=1 # suggested by errors in /var/log/Xorg.1.log 2015-3-1 If memory server, I tried modifying /etc/ttys (or something that looks like it) and rebooting, then retrying, but that didn't help. Here are some interesting(?) lines from the end of /var/log/Xorg.1.log: [ 16285.868] (II) VESA: driver for VESA chipsets: vesa [ 16285.869] (II) [KMS] drm report modesetting isn't supported. [ 16285.869] (WW) Falling back to old probe method for vesa [ 16285.869] (EE) Screen 0 deleted because of no matching config section. [ 16285.869] (II) UnloadModule: radeon [ 16285.869] (EE) Device(s) detected, but none match those in the config file. [ 16285.869] (EE) Fatal server error: [ 16285.869] (EE) no screens found(EE) [ 16285.869] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 16285.869] (EE) Please also check the log file at /var/log/Xorg.1.log for additional information. [ 16285.869] (EE) [ 16285.870] (EE) Server terminated with error (1). Closing log file. Removing my .fvwmrc file didn't make a difference. For what it may be worth, here is the output of 'echo $(l /dev/tty*) 21': crw-rw-rw- 1 root wheel 5, 14 Dec 21 08:19 /dev/ttype crw-rw-rw- 1 root wheel 5, 13 Dec 21 08:19 /dev/ttypd crw-rw-rw- 1 root wheel 5, 12 Dec 21 08:19 /dev/ttypc crw-rw-rw- 1 root wheel 5, 11 Dec 21 08:19 /dev/ttypb crw-rw-rw- 1 root wheel 5, 10 Dec 21 08:19 /dev/ttypa crw-rw-rw- 1 root wheel 5, 9 Dec 21 08:19 /dev/ttyp9 crw-rw-rw- 1 root wheel 5, 8 Dec 21 08:19 /dev/ttyp8 crw-rw-rw- 1 root wheel 5, 7 Dec 21 08:19 /dev/ttyp7 crw-rw-rw- 1 root wheel 5, 35 Dec 21 08:19
