petget0, a single container runs all of EasyOS

As I posted recently, I have been rethinking how containers are implemented in EasyOS. Overall, I want to make them simpler to use.

In the previous post, I explained that X server security in containers has been improved, and introduced a new container named 'petget0':

http://bkhome.org/news/201807/improved-x-server-security-in-easy-containers.html

The basic idea to make container usage extremely simple, is to do away with the need to create containers for running individual apps. Instead, there is just one container, pre-created, and all apps can be run in it.

The concept is simple: the petget0 container is a complete EasyOS, that does everything the main EasyOS does, in a separate desktop, and you can toggle between the container desktop and the main desktop. It is two separate operating systems, the difference being that the containerized one is highly locked down.

The name "petget0" is an arbitrary choice. After bootup, in the main desktop, you can see the petget0 container files here:

/mnt/wkg/containers/petget0/container

...so you can poke around in the container as much as you want. You are "outside" the container, in the main desktop, running as root, so have unlimited power.

Now, to flip into the containerized desktop...

In the JWM tray, you will see a process named "containerized apps", click that, and you will be flipped into the containerized desktop. This is what you will see:

The containerized desktop is running pekwm window manager and lxpanel tray. Everything runs as per normal, as you can see in the above snapshot. Everything, even the PETget Package Manager, so you can install packages -- these will install into the petget0 container, which is completely separate from the main desktop.

To flip back to the main desktop, press ALT-F6, that is, hold down the ALT key and tap the F6 key.

Note, I have set it up so that when EasyOS is booted up, it automatically flips into the containerized desktop. Because, it is likely that this is where you will mostly like to be.

Now for some technical details...

---

Technical notes

It is useful, for users and developers, to know how all of this is achieved "under the hood".  At bootup, the main desktop starts in the normal way, with Xorg, running JWM window manager and ROX-Filer for the desktop icons and wallpaper.

In /root/Startup, there are various scripts that run after X has started. To follow the trail from the commandline, /usr/bin/xwin is run, which launches Xorg and /root/.xinitrc. The latter launches various things, including /usr/sbin/delayedrun and finally JWM.

It is /usr/sbin/delayedrun that runs the scripts in /root/Startup. These are mostly applets that run in the JWM tray, such as battery-status and volume-control. It also runs /root/Startup/xephyr.

/root/Startup/xephyr launches the Xephyr server, then starts the container:

 Xephyr :1 -fullscreen -title "$TXT1" -name "xephyr" -zap -dpi "$DPI" -nolisten tcp &
 sleep 0.5
 #next, run window manager and panel inside petget0 container...
 ec-chroot petget0 pekwm-lxpanel

Xephyr is started fullscreen, so a black screen will appear. I have only tested this on my midi-tower PC, with Intel video, so I don't know if this fullscreen startup will work with other video hardware. I opted for fullscreen, as starting in a window has some problems.

Look at /usr/local/easy_containers/ec-chroot to see how it starts the container and launches it. Following the trail, the /ec-run script will run first in the petget0 container, which will then run /usr/bin/pekwm-lxpanel. The latter will launch pekwm and lxpanel.

pekwm, lxpanel

I chose these two rather than JWM, as had some show-stopper problems with running the latter in Xephyr. Though, that was when I was using Xephyr as a resizeable window. Now running fullscreen only, will revisit JWM.

pekwm and lxpanel have been compiled in my fork of OpenEmbedded (commits July 6, 2018):

https://github.com/bkauler/oe-qky-src/commits/master

I used a very old version of lxpanel, 0.2.9.0, partly because it is simple and does the job, and secondly because Puppy Forum member plinej created some patches for that version. I modified those patches to suite EasyOS, and they are in the github repo. What the patches do is add paths to where icons are kept in EASYOS, and to automatically load from the XDG .desktop files -- so no external menu converter is required, just restart lxpanel.

I am unfamiliar with pekwm and lxpanel, getting up to speed. With pekwm, a right-click brings up a menu, generated by the 'xdg2pekwm' uility, but it looks awful. If anyone has experience with pekwm, your input will be welcome!

Network access

I have not unshared the network namespace. The ultimate security would be to do so, but this is a maybe for the future. So, apps in the container use the main system Internet connection. This requires /etc/resolv.conf to be copied into the container, and this is done in the ec-chroot script.

However, it is likely that the network connection is not established at bootup, when the petget0 container is started, so /etc/resolv.conf is empty.

There is a fix for this, service-script /etc/init.d/petget0. This script runs when there is Internet connection, and copies /etc/resolv.conf into the container.

EasyOS has pup_event service management, my own creation to start and stop services when dependencies are met. Examine scripts /etc/rc.d/rc.services and /etc/rc.d/rc.services_ipc, and file /etc/eventmanager, to see how pup_event service management works.

Mount namespace

petget0 is pretty well locked down, though there are still some things that need to be done.

I would like to unshare the mount namespace, however, SeaMonkey crashes. But, only when accessing https sites. This is something that needs further investigation.

petget0 configuration file currently has these settings:

#For security, unshare these namespaces:
EC_NS_UNSHARE_MOUNT='false'
EC_NS_UNSHARE_UTS='true'
EC_NS_UNSHARE_IPC='true'
EC_NS_UNSHARE_NETWORK='false'
EC_NS_UNSHARE_PID='true'

....the ultimate aim is to set all of them to "true".

User zeus

There is a user:group named zeus:zeus. This can be used in containers to lock-out access as required. In EasyOS, like Puppy Linux, the user runs as root, having unlimited rights. In a container, the user is still "root", but with limited rights. Examine the ec-chroot script, and /ec-run to see how Linux Capabilites is used to restrict the rights.

The ec-run script is an example. It is owned zeus:zeus, with 700 permissions, so only zeus can use it. The password assigned to zeus is the same as that given at bootup, so only you know it.

Running as "root", in a container, does have one big advantage: copying files to and from the main root filesystem. It becomes a non-issue, no need to be concerned with file ownerships and permissions. That is, if, in the main desktop, you copy a file into the petget0 container, perhaps something that you want to open by an app in the container, no problem with it being owned by root, the app in the container will have full rights over it.

Enough rambling on, this post has become too long. But, it is good to document as much as possible. For me too -- I look at what I did a couple of years ago, and can't recall how it works, so I also need these posts to refresh my memory!

Tags: easy