Run Browser toolbox container with different SELinux Context : A Thread ✍🏾!

I’m testing toolbox, hoping to change it’s SELinux context. What I am trying to achieve is to test several applications with a sandbox context like sandbox_t. The applications should run unconfined in the sandbox, but not see the outside OS or break out.

I created a Thorium Browser toolbox and the SELinux context is unconfined_u:unconfined_r:spc_t:s0 according to :

ps -eZ | grep thorium
unconfined_u:unconfined_r:spc_t:s0 112497 pts/0  00:00:06 thorium
unconfined_u:unconfined_r:spc_t:s0 112511 pts/0  00:00:00 thorium
unconfined_u:unconfined_r:spc_t:s0 112512 pts/0  00:00:00 thorium
unconfined_u:unconfined_r:spc_t:s0 112514 pts/0  00:00:00 thorium
unconfined_u:unconfined_r:spc_t:s0 112543 pts/0  00:00:02 thorium
unconfined_u:unconfined_r:spc_t:s0 112545 pts/0  00:00:00 thorium
unconfined_u:unconfined_r:spc_t:s0 112609 pts/0  00:00:04 thorium
unconfined_u:unconfined_r:spc_t:s0 112721 pts/0  00:00:04 thorium
unconfined_u:unconfined_r:spc_t:s0 112841 pts/0  00:00:00 thorium
unconfined_u:unconfined_r:spc_t:s0 112924 pts/0  00:00:00 thorium
unconfined_u:unconfined_r:spc_t:s0 113084 pts/0  00:00:00 thorium
unconfined_u:unconfined_r:spc_t:s0 113131 pts/0  00:00:00 thorium
unconfined_u:unconfined_r:spc_t:s0 113143 pts/0  00:00:00 thorium

In the past I would do :
sandbox -X -w 1920x1080 -H temphome -T tmp -t sandbox_web_t thorium

Adding toolbox to the workflow, how can I change this context? What are the recommended selinux context for a container running from toolbox

Any container folks change their selinux context for their workflow, or have any recommendations?

Would doing podman run --security-opt label=type:sandbox_t thorium work, or do I need to create an image or directory structure for the application then change it’s context?

I will be adding my findings below.

Well, this has not gotten anywhere with toolbox. It’s a bit limiting in what can be done and has also dropped config files in my /home/<User>/.config/ . I expected this, but just don’t see the viability of using toolbox over something like a proper OCI image like Podman for experimental software. Setting up toolbox is easy and it downloads the minimal fedora image for sure, but without properly containing the program with selinux context or being able to modify them, and further adds to my point.

I’ve done some more digging, podman inspect thorium gives me the config.json file with the arguments and a ton of other info.

podman inspect thorium 
          "Id": "e5c18af4f287505b299e89cd307c313218f95b04babd53fba78d308d0c89b350",
          "Created": "2024-01-11T19:10:04.620679469-05:00",
          "Path": "toolbox",
          "Args": [

This offers a more intriguing prospect for customization of where the application should be confined on my system particularly --home :exclamation: this would allow for us to define where in our /home we could set up a directory to confine the application and potentially apply a selinux sandbox context to.

More to come. . .

Editing the toolbox config file resulted in the changes being reverted upon reopening the container. So we’re gonna have to try something different.

i did not intend to create images for all the browsers I want to test, but it looks like to get the customization I need with SELinux, it’s the only way. Let’s create a image using podman defining the config/dockerfile and installing our experimental browser in the minimal fedora image. I will work on defining the changes for --home which might not be necessary if we mount and work from the image, and the selinux context unconfined_u:unconfined_r:spc_t:s0 to a sandbox_file_t changes with podman when we create the image itself.

Moderators : If you need to you can move this to another side of the forum, maybe Water Cooler? or whatever.

1 Like

Your choice is fine. Hopefully, we have a #confineduser tag in the ask category soon.

The toolbox is one of the two issues on my list to create a report at the Fedora SELinux repository (one of the issues that force me to stick with sysadm_u). But I have not yet had time to create one about it (we indeed need to change the defaults of toolbox in Fedora). If you want and have the time, feel free to create a report:
Issues · fedora-selinux/selinux-policy · GitHub

Also, the feedback might also support you in resolving your issues.

You can read the issue tickets from me (py0xc3) and from the user PhysicsIsAwesome to have some examples of what type of data to provide.

If you have already some suggestions of how to change the defaults, feel free to add them.

A generic question: can you enter a default toolbox with toolbox enter ? At least on my KDE, toolbox breaks already at this point, but I consider the possibility that the issue in KDE is linked to a SE denial that occurs earlier in KDE environments and that has a wide impact subsequently. (Sorry for adding questions rather than solving yours :frowning: )

However, I do not think that it is possible to remove a confinement within toolbox: the kernel imposes it on the whole user account and everything contained. In the end, the toolbox only “simulates” root and such, but in fact, everything is the same “confined” user account. It has not even its own systemd process. So it should be fully confined if the superordinated user is, even if toolbox outputs at some points that it is unconfined (its comparable to root: you can become root in toolbox, but once you do something that can be done only by the “real” root in the system outside toolbox, the toolbox will fail)

Yet, you might try to find out how to allocate and adjust labels that effectively “open up” everything within toolbox as long as it remains inside the toolbox. But I expect that will be a complex and vulnerable task.

Funny you ask, I am about to do just this right now as my machine is going to build one just for Thorium to test, so I’ll post later on or tomorrow.

I welcome any/all questions related to sandbox, container, selinux context pertaining to tesing builds and the like. Maybe we can solve each others problems ! I just feel like the container workflow ( if done right ) can be a strong tool for layman’s looking to keep security/privacy and still play around with software freely. toolbox should do this with the ease of its use, but podman and selinux are lacking in both Docs and Usage IMO. . . All without the need for a VM.

I use toolbox only with the default Fedora image in order to get vlc within. I don’t want to have rpmfusion enabled on my main system for one package and its dependencies. So it is a very superficial use case.

So far I have not done much since I am anyway forced to remain with sysadm_u because of one other problem (which I also have not yet had the time to report :dizzy_face: ). My next step would have been to create a report at the SELinux repo. Hopefully, this will foster some discussion and finally adjustments about proper default labelling.

Absolutely agreed. When I had to manage it the first time, it was already a mess to find out the differences of user_home_dir_t and user_home_t, although some of the current issues I have can be solved by that (more precisely, to make user-specific directories outside ~ to user_home_dir_t) → much user actions of Fedora go beyond ~ and lead to the need of automatically creating appropriate labeling of directories/files (this starts already with what occurs in /run → e.g., /run/media/<username>) → I am not sure if your issues can be linked to that as well, but you might have a look if your toolbox/podman has issues at some places outside ~ where a folder is intended to be user-specific and user-owned but not treated that way by SELinux (my example for such a folder remains /run/media/<username>) → I have not deeply analyzed your very issue, but checking this is maybe the only thing I can help with at the moment in that case (I am not an expert for podman).

However, I am a little skeptics about container workflows on graphical desktop environments, as I see several issues rise, some technical, some social: before going into this SELinux stuff, I also evaluated graphical use cases with podman. I found out early that it is possible to make use of graphical tools in containers, but usually, these made it necessary to disable many if not most security features. All solutions I found for graphical applications have disabled the containerization at some places. At the same time, the containers cause complexities that can make the job of SELinux “harder” (harder for SELinux, harder for the admin who has to find proper labeling, while harder & complex implies more vulnerable), whereas SELinux on itself is able to enforce separation of graphical stuff without such issues in a very precise and still comprehensible way.

The other thing with container solutions in such use cases is, e.g., if people are underway/mobile, the many containers can cause massive downloads and processing to get all that stuff updated on time, so that I see a risk that users don’t do their updates on time → one problem here is that no systemd process is running within the containers (no auto updates and such are possible from within in a reliable way), so everything has to be done from outside or triggered manually, whereas from outside means, complete replacement of the container each time. This is why I stick with SELinux and only have this simple toolbox for vlc

In the Fedora 2x days we used systemd-nspawn to run a minimal Debian so we could have Spotify ! but the parameters, flags, and forwarding Xorg or Xephyr was a pain. . .

I think it’s viable, and this usecase with experimental browsers like Thorium is kind of a way for me to prove that.

  1. Thorium gained popularity because of Content creators, and how “Fast” the browser is.
  2. No one thought to check who or what was going on in t’s development.
  3. I was asked to advise folks who contacted me : So I said, run in in a vm or container. . . Or SELinux sandbox. Sometimes VM’s are not practicle. . Containers can be.
  4. Yup, it happened, Thorium’s development was shaky for a while with many questionable actions. My bigger picture is : We can still use it, with the proper safeguards. We have them at our disposal ! containers, toolbox, selinux !

So we don’t have to compromise for security with convenience. Maybe along this journey, I help document some of this for the layman’s ! :upside_down_face:

The build worked. . . Thorium Browser running on minimal fedora:latest now rebuild with selinux context.

Indeed an interesting case (I admit I have no knowledge about Thorium). Feel free to keep us updated! In any case, your experiments might improve our knowledge about the behavior of SELinux in conjunction with containers!