=== AppJail, AppScripts and Sandboxed X11 Applications Links: + link:https://github.com/DtxdF/AppJail[AppJail on GitHub] URL: link:https://github.com/DtxdF/AppJail[] + link:https://github.com/DtxdF/appscript[AppScript on GitHub] URL: link:https://github.com/DtxdF/appscript[] + link:https://github.com/DtxdF/x11appjail[x11appjail on GitHub] URL: link:https://github.com/DtxdF/x11appjail[] + Contact: Jesús Daniel Colmenares Oviedo **AppJail** is an open-source BSD-3 licensed framework entirely written in POSIX shell and C to create isolated, portable and easy to deploy environments using FreeBSD jails that behaves like an application. **AppScript** is a very lightweight and easy-to-use tool for creating self-extracting executables. OS-level virtualization is not as perfect as hardware-level virtualization: a vulnerability in a device not hidden within the jail could pose a risk to the host, but, if done correctly, it is much better than running an application directly from the host. Jails are the implementation of OS-level virtualization for FreeBSD. With jails, many things can be easily restricted: link:https://appjail.readthedocs.io/en/latest/limits/[limiting resources], link:https://appjail.readthedocs.io/en/latest/DEVFS/[restricting access to /dev devices], limiting the filesystem, link:https://github.com/DtxdF/AppJail/wiki/filter[restricting the network], and many other aspects. All transparently to the application running within the jail. However, one issue, specifically with X11 applications, is the lack of isolation. Users often misuse the `xhost +` trick to run an X11 application inside the jail and display the application on the host's X server. This poses a security risk because, even though the X11 application runs inside the jail and even though it does so as an unprivileged process, it can obtain a great deal of information from the host. Therefore, a compromised application, one with a backdoor, or simply one that collects a lot of information for «telemetry purposes» could be a nightmare with this setup and, in the worst-case scenario, compromise the host. A new command has recently been implemented in AppJail to solve this problem: man:appjail-x11[1]. This command runs an application inside the jail but displays it on a new X server created by Xephyr, which is already authenticated with **MIT-MAGIC-COOKIE-1**. This is much simpler and lightweight than setting up an SSH server inside the jail, creating a key pair for this purpose, connecting to the jail, etc. However, this command is not limited to just that: you can resize the Xephyr window, and your DE/WM will be refreshed accordingly, as this command is capable of detecting such changes. However, while much has been achieved with this command, the user must install a DE/WM and the application inside the jail, and perhaps install a custom .desktop file on the host. This can be automated using Makejails, and advanced users will be fine with that, since they love customizing everything, but for the average user (or even for me), what I wanted was to distribute applications so that users would not have to do anything more than simply run the application, and that is what x11appjail aims to solve. link:https://github.com/DtxdF/x11appjail[x11appjail] is a repository containing pre-made scripts for deploying certain X11 applications using appjail-x11, which automates the installation of the .desktop file, the icon, the creation of the jail via Makejails, and some reasonable default environment variables that can be easily modified at runtime. However, the repository actually exacerbates the usability issue: now the user has to clone and pull updates, which may be enough for some users, but what I wanted was reasonably good usability of the application and the ability to easily isolate it in a jail. Therefore, I wrote link:https://github.com/DtxdF/appscript[appscript], which creates SFX files in ELF format, and these are automatically created with each new release of that repository thanks to a GitHub workflow. Sponsor: https://www.patreon.com/appjail