Subject: Firejail

From: [email-masked]
Date: Mon, 19 Jul 2021 08:16:45 +0200 (CEST)

I've noticed that `firejail` isn't available in the repositories. Will it be available in the future?

Also, the Tor browser doesn't work with `musl`. Is there a workaround?

---

From: Ariadne Conill <[email-masked]>
Date: Mon, 19 Jul 2021 02:26:45 -0500 (CDT)

Hi,

> I've noticed that `firejail` isn't available in the repositories. Will it be available in the future?

`firejail` has a rather problematic design, so we dropped the package as 
we were not confident in its dependability as a security tool.

There are other tools like bubblejail that may work for your use case.

> Also, the Tor browser doesn't work with `musl`. Is there a workaround?

I'm not familiar with the modifications made to Firefox with tor-browser, 
but you should be able to just use Firefox with Tor directly, I think.

Ariadne

---

From: Wolf <[email-masked]>
Date: Mon, 19 Jul 2021 12:17:03 +0200

On 2021-07-19 02:26:45 -0500, Ariadne Conill wrote:
> `firejail` has a rather problematic design, so we dropped the package as we
> were not confident in its dependability as a security tool.

Would you be able to recommend some reading on the topic? Since I'm
using it on my laptop I would like to know more.

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

---

From: Ariadne Conill <[email-masked]>
Date: Mon, 19 Jul 2021 05:28:13 -0500 (CDT)

Hello,

> using it on my laptop I would like to know more.

The basic gist of it is that we weren't really thrilled about having a 
SUID program with several CVEs that describes itself as a security tool in 
the repo.

Although the CVEs have been mitigated, they were caused by lack of 
experience writing C code, which means there are likely many more CVEs in 
firejail just waiting to be discovered.  Given that it's SUID and has to 
be SUID in order to do its thing (due to the way its implemented), I hope 
you can understand the skepticism.

Ariadne

---

From: "Laurent Bercot" <[email-masked]>
Date: Mon, 19 Jul 2021 11:15:43 +0000

>The basic gist of it is that we weren't really thrilled about having a SUID program with several CVEs that describes itself as a security tool in the repo.
>
>Although the CVEs have been mitigated, they were caused by lack of experience writing C code, which means there are likely many more CVEs in firejail just waiting to be discovered.  Given that it's SUID and has to be SUID in order to do its thing (due to the way its implemented), I hope you can understand the skepticism.

  Ariadne is diplomatically understating the severity of the situation.
Since I do not represent Alpine in any capacity, I do not have to take
the same precautions.

  The reality is that firejail is a catastrophe that has already happened
and is waiting to happen again. Its design and code are so terrible that
any semi-competent QA team would veto it on the first read; the fact 
that
it advertises itself as a "security tool" would be laughable if it 
weren't
so tragic for the users that have been scammed by it.

  The only reason why firejail has made it into distributions is that 
free
software painfully lacks manpower for peer review. This is not an
indictment of distribution maintainers, who are underpaid and overworked
(and code review, as far as maintainer tasks go, is one of the most
thankless ones). This is the unfortunate reality - there is basically no
quality assurance for random free software, so FOSS is like a box of
chocolates: you never know what you're going to get. Most of the time,
people who invest energy into coding FOSS are good at it, so the 
software
is at least passable even with paltry best-effort QA; unfortunately,
firejail falls into the other category.

  If users like firejail for its simple frontend, it means that there's
a need for a similar tool with a similar frontend but better
implementation. If it doesn't exist yet, add it to the already huge
list of "software that needs to be written".

--
  Laurent

---

From: [email-masked]
Date: Mon, 19 Jul 2021 10:53:31 +0200 (CEST)

Jul 19, 2021, 07:26 by [email-masked]:

> `firejail` has a rather problematic design, so we dropped the package as we were not confident in its dependability as a security tool.

The main reason I use Firejail is because it has a simple front-end. For instance, if I don't want an application to see the contents of my local filesystem, I could simply use the `--private` flag. I could use `--net=none` to prevent the application from accessing the network. Firejail also has extensive documentation, which makes it easy to figure things out.

I understand that one shouldn't rely solely on Firejail for security/privacy, although I think it's a great tool to have in the arsenal. I would like to request the re-addition of Firejail into the official repositories.

> I'm not familiar with the modifications made to Firefox with tor-browser, but you should be able to just use Firefox with Tor directly, I think.

Yes, I could do this. Although Tor provides additional anti-fingerprinting measures, which Firefox doesn't provide by default.

Also, I noticed that `apparmor` is still in in the testing repository. How unsafe is it to run your systems, especially production-facing ones, without `apparmor`? Is there an alternative that's currently provided?

"All userland binaries arecompiled as Position Independent Executables (PIE) with stack smashingprotection. These proactive security features prevent exploitation of entireclasses of zero-day and other vulnerabilities."

I am not sure what the above lines mean. Does PIE, in a way, function as a kind of alternative to apparmor?

(I am not a security-expert, so please bear with my questions. I'm just trying to harden my system, as a hobby.)

---

From: Ariadne Conill <[email-masked]>
Date: Mon, 19 Jul 2021 05:23:09 -0500 (CDT)

Hi,

On Mon, 19 Jul 2021, [email-masked] wrote:

> The main reason I use Firejail is because it has a simple front-end. For instance, if I don't want an application to see the contents of my local filesystem, I could simply use the `--private` flag. I
> could use `--net=none` to prevent the application from accessing the network. Firejail also has extensive documentation, which makes it easy to figure things out.
> 

Unfortunately, the SUID nature of firejail is sufficiently problematic 
that it won't return until there is a way to run firejail without being 
SUID.

> Also, I noticed that `apparmor` is still in in the testing repository. How unsafe is it to run your systems, especially production-facing ones, without `apparmor`? Is there an alternative that's

It is perfectly safe to run your systems without AppArmor or SELinux. 
These systems just provide mechanisms for building and loading policy 
statements into the kernel.  The normal UNIX security primitives, while 
not as advanced, are sufficient for the majority of production Alpine 
systems.

With that said, there is some interest amongst some developers to make 
AppArmor a first-class citizen in Alpine 3.15, but it's still early days 
of that effort, so we'll see how it plays out.  I think it would be nice 
to have, but I sleep well at night without it.

> "All userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. These proactive security features prevent exploitation of entire classes of zero-day and
> other vulnerabilities."
> 

AppArmor is a policy framework, PIE is a way of compiling programs to make 
them have a more randomized address space layout.  They are unrelated to 
each other.

Ariadne

---

From: [email-masked]
Date: Mon, 19 Jul 2021 18:52:46 +0200 (CEST)

Do you know how to write Firejail's `firejail --private executable` equivalent for Bubblewrap? I never use my browser to access/upload files from my local filesystem, so I don't see why it should have access to them.

I tried looking it up, but `bubblewrap` seems much more complicated than Firejail. I haven't yet wrapped my head around it.

---

From: Donoban <[email-masked]>
Date: Mon, 19 Jul 2021 18:51:35 +0000

On 19/7/21 16:52, [email-masked] wrote:
> Do you know how to write Firejail's `firejail --private executable` 
> equivalent for Bubblewrap? I never use my browser to access/upload 
> files from my local filesystem, so I don't see why it should have 
> access to them.
>
> I tried looking it up, but `bubblewrap` seems much more complicated 
> than Firejail. I haven't yet wrapped my head around it.

Take a look to bubblejail which is a simpler wrapper for bubblewrap and 
also has a basic GUI, bubbejail-config.

On bubblejail all Instances have their private home (stored in 
~/.local/share/bubblejail/instances/) and then you can mount other 
folders from your real home if needed.

Donoban

---

From: Donoban <[email-masked]>
Date: Mon, 19 Jul 2021 18:41:38 +0000

El 19/7/21 a las 7:26, Ariadne Conill escribió:
> I'm not familiar with the modifications made to Firefox with 
> tor-browser, but you should be able to just use Firefox with Tor 
> directly, I think.

Another problem using upstream firefox with tor connection is that you 
will get more captchas than using tor-browser, also I think that you 
can't reach .onion addresses.

A possible "solution" (if you are ok running flatpak) is using Micah Lee 
launcher https://github.com/micahflee/torbrowser-launcher.

Donoban

---

From: Parke <[email-masked]>
Date: Mon, 19 Jul 2021 11:19:49 -0700

> Also, the Tor browser doesn't work with `musl`. Is there a workaround?

If Arch Linux provides the Tor browser, you could try installing
Arch's version of the Tor browser inside an Lxroot.

Demo #3 at the below link shows how to install and run the Arch
version of the Chromium browser inside Lxroot.  I have not tried
installing the Tor browser inside Lxroot.

https://github.com/parke/lxroot

Also, depending on your requirements, Lxroot might be an alternative
to other uses of Firejail.