Re: [arch-general] sandboxing
On Sun, Feb 05, 2017 at 11:08:09AM +0530, Shridhar Daithankar wrote: > ok. It confirms my understanding that X clients can listen to each other's > events and modify them. > > But in xwayland, things are bit different. > > https://lists.freedesktop.org/archives/wayland-devel/2014-January/012777.html > > As the thread suggests, if there is a separate X server instance per xwayland > application, they won't be able to snoop on each other. Yes, and you don't need wayland for that... If copy-paste between apps is not required, xephyr should be sufficient. AFAUI, selinux sandbox does that https://dwalsh.fedorapeople.org/SELinux/Presentations/sandbox.pdf . > > Btw. to fully prevent keyloggin on wayland, you need to do more, e.g. by > > sandboxing, since there are ways to work around the security of wayland > > where the default linux security model is weaker then that of the > > wayland architecture. > > > > More info here: > > https://www.reddit.com/r/linux/comments/23mj49/wayland_is_not_immune_to_keyl > > oggers/ > > Exactly. If I am running chromium with firejail, which whitelists what > chromium can do to the file system(even better with --private); the browser > cannot tamper with .profile/.bash_profile or .ssh. See, this is the problem: Why would a browser need these files? File access should only be possible with user interaction (via a file-open dialog). Cheers, -- Leonid Isaev
Re: [arch-general] sandboxing
Am 05.02.2017 um 06:38 schrieb Shridhar Daithankar: >> this point is about the insecurity of the X Windows System architecture, >> which basically assumes that all applications are to be trusted. There >> is no build in security, therefore failing modern threat models completly. >> >> This explains it pretty well I guess: >> https://theinvisiblethings.blogspot.de/2011/04/linux-security-circus-on-gui-> >> isolation.html > > ok. It confirms my understanding that X clients can listen to each other's > events and modify them. > > But in xwayland, things are bit different. > > https://lists.freedesktop.org/archives/wayland-devel/2014-January/012777.html > > As the thread suggests, if there is a separate X server instance per xwayland > application, they won't be able to snoop on each other. > Sounds like what some sandboxing tools try to do with xpra and other additional x instances. However the default on wayland/xwayland is as described. You can easily try weston. Just install and enter 'weston' and you will get a weston instance where you can try this out with xinput >> Btw. to fully prevent keyloggin on wayland, you need to do more, e.g. by >> sandboxing, since there are ways to work around the security of wayland >> where the default linux security model is weaker then that of the >> wayland architecture. >> >> More info here: >> https://www.reddit.com/r/linux/comments/23mj49/wayland_is_not_immune_to_keyl >> oggers/ > > Exactly. If I am running chromium with firejail, which whitelists what > chromium can do to the file system(even better with --private); the browser > cannot tamper with .profile/.bash_profile or .ssh. > Not so sure using firejail will not actually decrease security in light of the recent wave of local root exploits... signature.asc Description: OpenPGP digital signature
Re: [arch-general] sandboxing
On Sunday 5 February 2017 6:10:51 AM IST sivmu wrote: > Am 05.02.2017 um 05:16 schrieb Shridhar Daithankar: > > On Saturday 4 February 2017 7:28:31 AM IST sivmu wrote: > >> As long as the application has access to the xwayland instance, which is > >> by default the case when xwayland is available, it can influence all > >> other applications that still use the x-protcol. > > > > Just to understand, if there are two applications using xwayland, under a > > wayland session, will they be still able to look at each other's > > resources? > > > > If the answer is no, the security is equivalent to the wayland > > applications, since xwayland instance is essentially a sandbox? > > Not sure what you mean with resources. devices and events, mostly. > this point is about the insecurity of the X Windows System architecture, > which basically assumes that all applications are to be trusted. There > is no build in security, therefore failing modern threat models completly. > > This explains it pretty well I guess: > https://theinvisiblethings.blogspot.de/2011/04/linux-security-circus-on-gui-> > isolation.html ok. It confirms my understanding that X clients can listen to each other's events and modify them. But in xwayland, things are bit different. https://lists.freedesktop.org/archives/wayland-devel/2014-January/012777.html As the thread suggests, if there is a separate X server instance per xwayland application, they won't be able to snoop on each other. > Btw. to fully prevent keyloggin on wayland, you need to do more, e.g. by > sandboxing, since there are ways to work around the security of wayland > where the default linux security model is weaker then that of the > wayland architecture. > > More info here: > https://www.reddit.com/r/linux/comments/23mj49/wayland_is_not_immune_to_keyl > oggers/ Exactly. If I am running chromium with firejail, which whitelists what chromium can do to the file system(even better with --private); the browser cannot tamper with .profile/.bash_profile or .ssh. -- Regards Shridhar
Re: [arch-general] sandboxing
Am 05.02.2017 um 05:16 schrieb Shridhar Daithankar: > On Saturday 4 February 2017 7:28:31 AM IST sivmu wrote: >> As long as the application has access to the xwayland instance, which is >> by default the case when xwayland is available, it can influence all >> other applications that still use the x-protcol. > > Just to understand, if there are two applications using xwayland, under a > wayland session, will they be still able to look at each other's resources? > > If the answer is no, the security is equivalent to the wayland applications, > since xwayland instance is essentially a sandbox? > Not sure what you mean with resources. this point is about the insecurity of the X Windows System architecture, which basically assumes that all applications are to be trusted. There is no build in security, therefore failing modern threat models completly. This explains it pretty well I guess: https://theinvisiblethings.blogspot.de/2011/04/linux-security-circus-on-gui-isolation.html All of that is equally true for x-wayland, which is just a modified xserver run alongside a wayland instance to allow x applications to run on wayland compositors like weston. >> >> Only the input/output of applications using only the wayland protocol >> are somewhat safe from this attack vector. >> To fully close this risk, full adaption of wayland in all applications >> is necessary, because then you no longer need any xserver. > > Again, if a wayland application and a xwayland application are running side- > by-side, the xwayland application cannot of peek into the resources of > wayland > application right? > If I am not mistaken it does not matter if an application is run on xwayland od directly on wayland, in regards to what it can capture. All applications can see input/putput of all other applications using the X Server Protocol, no matter what they themselfs are using. You can test this by running xinput on a terminal like in the linked article explained. No matter where you run it, you can capture the input of x applications. You can however not capture the input of wayland applications (at least not that easily) So if you want to avoid that other applications can snoop e.g. on your terminal input where you enter your root password, you need to use one that can work directly on wayland. Termite is a great terminal that supports wayland. Btw. to fully prevent keyloggin on wayland, you need to do more, e.g. by sandboxing, since there are ways to work around the security of wayland where the default linux security model is weaker then that of the wayland architecture. More info here: https://www.reddit.com/r/linux/comments/23mj49/wayland_is_not_immune_to_keyloggers/ I hope I did not mess up that explaination, if I did someone please hit me. signature.asc Description: OpenPGP digital signature
Re: [arch-general] sandboxing
On Saturday 4 February 2017 7:28:31 AM IST sivmu wrote: > As long as the application has access to the xwayland instance, which is > by default the case when xwayland is available, it can influence all > other applications that still use the x-protcol. Just to understand, if there are two applications using xwayland, under a wayland session, will they be still able to look at each other's resources? If the answer is no, the security is equivalent to the wayland applications, since xwayland instance is essentially a sandbox? > > Only the input/output of applications using only the wayland protocol > are somewhat safe from this attack vector. > To fully close this risk, full adaption of wayland in all applications > is necessary, because then you no longer need any xserver. Again, if a wayland application and a xwayland application are running side- by-side, the xwayland application cannot of peek into the resources of wayland application right? Thanks. -- Regards Shridhar
Re: [arch-general] sandboxing
On Fri, 2017-02-03 at 17:49 +0100, Bart De Roy via arch-general wrote: > Error verifying signature: parse error > --pyi53mwzyx2s2ll6 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > hello > > I've been postponing looking into browser isolation > since I started using Wayland about a year ago. > > Does anyone have pointers, experiences or comments on > this topic with regard to Xwayland? If I'd want to > disassociate parts of chromiums execution context, > what are common, good options? > > cheers, Bart > > --pyi53mwzyx2s2ll6-- The vast majority of Chromium's code already runs in far tighter sandboxes than can be made externally via namespaces, MAC, etc. Using an outer sandbox can help in the case where a sandbox bypass exploits the browser's broker process responsible for managing the renderers. The easiest way out is often a kernel exploit despite the extremely restricted system call whitelist which doesn't even include calls like open(...). If you want to strength the existing sandbox, a hardened kernel goes a long way to mitigating one of the two primary attack vectors for escaping the sandbox. There might be some value in containing the file access of the outer sandbox even if it's not really contained, because an attacker might only be able to influence it to incorrectly open any file, etc. if they only have code execution in a renderer without a code execution exploit for the outer part. I don't think there have been many bugs like that though, it's mostly just a full sandbox escape in which case the outer sandbox would actually need to contain usage of X11, pulseaudio, dbus, etc. So you definitely need more than simply MAC or namespaces + X11 / pulse access granted. Indirect access to X11 via another instance of it isn't great either. signature.asc Description: This is a digitally signed message part
