Support `sudo` again for Linux compatibility

[morgant]

The only reason that Xsunaba is currently listed as "for OpenBSD" is that I converted Milosz's original script from using sudo to doas. It should be easy to support either sudo or doas, but I don't currently have a Linux environment running X11 to test this in.

I'm not sure why the original script was using sudo su - $SANDBOX_USER instead of sudo -u $SANDBOX_USER. The latter syntax would be easier to switch between sudo and doas as doas also supports -u.

[jon1enforce]

at openbsd, a sandbox is similar to a non-root-user with restrictions.. And linux compability is not guaranteed, because openbsd uses xenodm, a fork of xdm. And we have also wayland right now on linux. The script can be used to run applications on a openbsd server from remote. It is a nice tool for openbsd virtual machine managements. Seems so, do it? just tested a lot.. Where did you find this script? Any references?

[morgant]

@jon1enforce Truthfully, OpenBSD doesn't really have sandboxes other than chroot, so nothing quite like FreeBSD's jails, so Xsunaba is really just doing a best attempt of 'sandboxing' X11 applications (to prevent or limit other X11 applications from having access to snoop on various X11 events, especially keyboard input) by running those applications as a different user and within a Xephyr virtual X11 display which doesn't have access to the parent X11 display.

That said, some OpenBSD X11 applications have been updated to use OpenBSD's pledge(2) & unveil(2) functions to further restrict access to the file system, but the number is relatively small and effectiveness is not guaranteed.

This is based on a script by Milosz Galazka (that's an Internet Archive link, since the original page is no longer available; I've also added the Wayback Machine link to the README), which he gave me permission to modify and release under the MIT license back in 2020. So, it did originally work under Linux, but — as you rightfully point out — many (most?) Linux distributions are now defaulting to Wayland (OpenBSD now has limited support for Wayland in ports), which has a different security model and is incompatible with Xsunaba. I have not yet investigated whether the XWayland compatibility layer would allow the use of Xsunaba, but since the overall architecture and security considerations are completely different, it's probably not worth it.

[morgant]

@jon1enforce Also, I like your thought of using this with OpenBSD guest VMs, though I haven't personally tested that.

[jon1enforce]

my thoughts on OpenBSD guest VMs (not as good as freebsd-jails) are similar to a video, i just watched.. Run X11/GUI apps seamlessly on OpenBSD VMM with Xephyr I removed virtual machines on openbsd kernel right now, because i have a bad feeling on virtual machines(it is often used by hackers...(like for example that big amount of java exploits only works so well, because it is based on virtual machines...a double edged knife..pegasus trojan(NSO Group[crafted in israel]) seems also benefit from virtual machines)). I just tested default applications and it is pretty nice, doing all jobs for me. Virtual machines seems play a big role in server applications, with multiple participants, like "let us think about freebsd-jails".... When we want to "control" the users on a freebsd machine not disturbing each other -- we give (as host) just jails to each client. That is pretty easy (Sony playstation OS is based on freebsd). Let us think about a playground(or playstation) based on openbsd -- Xsunaba should do the same job as jails. do it? Can i take Xsunaba to run(as host) multiple instances of game-sessions, as admin, as user management, if i do not know about compromised games as software? It should prevent much damage..just like the job of "mandatory access control". I will test anything more(modifications for multiple clients), and give reports here. Also with kernel modifications... edit /etc/bsd.re-config 0) 1) disable vmm 2) disable bios 3) disable ... ...

I also need write permissions to subfolders on /home/xsunaba/project/project.py Now, it is only allowed to write on /home/xsunaba/, but this is not practical for most things... And xsunaba seems not prevent from read.. at all. Read access control is missing, but it is also missing at unveil, i guess. Xsunaba do not deny read access on usb ports for examples, like: https://learn.microsoft.com/en-us/answers/questions/1377674/deny-read-access-from-removable-usb-drives umask should do it, like umask 077 or so..

[jon1enforce]

@enhancement A default umask setting of 077 causes files and directories created by users to not be readable by any other user on the system...

find / -name .cshrc

=/home/user/.cshrc =/home/xsunaba/.cshrc =/root/.cshrc =/.cshrc EDIT..

nano /home/xsunaba/.cshrc

umask 022 umask 077#most restictive, suitable for multiple users on one server. Deny READ and WRITE umask 027 umask ...

the .cshrc file on freebsd looks more advanced... https://gist.github.com/darkgeek/889dec88d56ec4a89953

..Also on openbsd this should do the job..like adding read access control..

prevent unnecessary copying: Xephyr -extension FD-passing shared client-server memory..[we have address space layout randomization, so it makes sense..] Xephyr -extension MIT-SHM here is a nice playground for servers...looks much more promising: https://kristaps.bsd.lv/mult/