Mull / Hardened firefox security?

DeletedUser98

GrapheneOS What would be, from a security perspective, the better choice then: Firefox as flatpak, Firefox as a distribution package, or tar.bz2 from the Mozilla website?

wuseman

DeletedUser98
Firefox as a distribution package running inside of Firejail with seccomp, AppArmor and noroot.

xxx

DeletedUser98

Long time firefox desktop user here:

You want to go with your distributions package. 2nd best are the mozilla tars.

GrapheneOS

wuseman Firejail is extremely problematic and shouldn't be recommended.

Themble

GrapheneOS Could you please elaborate on that?

mmmm

As a user, I risk severe moderation or even banishment for baselessly claiming things in the forum, without some kind of 'proof' to my claim. Can a representative of the project please add some clarity to the claims against Cromite. I ask, as I use Cromite! Its a project often lauded in privacy circles, as Bromite was before it. I'm probably not the only one now a little concerned that the makers of the phone os we use states that a previously considered 'safe' browser is actually 'untrustworthy' in their opinion. Thanks.

locked

mmmm Did they state that it was unsafe? I think what they have implied is that it does not meet the project's standards for security.

mmmm

locked Did they state that it was unsafe?

They said:

GrapheneOS Bromite is an insecure, dead project and we recommend against using Cromite since it rolls back security and adds a bunch of questionable changes. It's also not a trustworthy project. It may be marked with a warning in the future.

locked

mmmm They said it was not trustworthy, which I would define (in this context) to mean the developers are not trusted to make good security or privacy implementations to the cromite browser. Don't confuse that to necessarily mean unsafe. It does not meet GrapheneOS's security standards. Some reasons have been listed below...

matchboxbananasynergy

Cromite makes a lot of choices that make it a subpar choice, and in my opinion, doesn't prioritize security.

Some examples of this:

Addition of JPEG-XL, which is a lot of additional attack surface over Chromium.
Addition of Eyeo's adblocking engine, written in C++ (memory unsafe). Eyeo is the company that bought "uBlock" (not uBlock Origin) and does "acceptable ads". Their code contains tracking that the maintainer of Cromite has to remove. Missing something there wouldn't be good. It's a very strange choice to add to the browser.
Cromite does not support CFI. It used to, but then it broke, and instead of fixing the issue, they simply stopped using it.
Of course, they also don't use MTE, which Vanadium does on devices supporting it.

Cromite is the successor to Bromite, a now-dead project that changed its licensing to GPLv3 and wouldn't share patches with Vanadium despite taking from it. All in all, I personally see no reason why it's so widely recommended in so called "privacy circles".

mmmm

matchboxbananasynergy they're all choices one makes when deciding in a browser to use for whatever task they choose.

I was more referring to the 'untrustworthy' label the project was designated by GraoheneOS a couple of comments ago. Its one thing having and opinion of unsatisfactory security, totally another to be deemed untrustworthy in general. I just really wanted to know why they're apparently untrustworthy as a whole.

Just to edit, I'm not arguing or making any point. I use Cromite for one aspect of my browsing and I am surprised by the designation.

TheGodfather

matchboxbananasynergy Taking from Vanadium while preventing sharing code the other way is trustworthy behavior to you?

Was that a licensing issue?

matchboxbananasynergy Cromite does not support CFI. It used to, but then it broke, and instead of fixing the issue, they simply stopped using it.
Of course, they also don't use MTE, which Vanadium does on devices supporting it.

Tbf no Chromium browser outside of Vanadium and Mulch does that on Android

TheGodfather

matchboxbananasynergy Cromite does not support CFI. It used to, but then it broke, and instead of fixing the issue, they simply stopped using it.
Of course, they also don't use MTE, which Vanadium does on devices supporting it.

Do these points still apply? Afaik Chromium (including Brave and Cromite) now support PAC and BTI as a form of CFI, even though no type-based CFI. Also it looks like they show MTE as enabled in their PartitionAlloc Memory Tagging flags.

thmf

whatname WASM is dangerous. I'm glad that im using Cromite, which does have a global switch to disable it (V8)

Since you mentioned WASM is dangerous it seems like you value security. Well, I'd be very cautious with Cromite then. Here are just a few quotes from the project members who (I assume) you trust since you're here:

https://discuss.grapheneos.org/d/10550-mull-hardened-firefox-security/52

matchboxbananasynergy Cromite makes a lot of choices that make it a subpar choice, and in my opinion, doesn't prioritize security.
Some examples of this:
Addition of JPEG-XL, which is a lot of additional attack surface over Chromium.
Addition of Eyeo's adblocking engine, written in C++ (memory unsafe). Eyeo is the company that bought "uBlock" (not uBlock Origin) and does "acceptable ads". Their code contains tracking that the maintainer of Cromite has to remove. Missing something there wouldn't be good. It's a very strange choice to add to the browser.
Cromite does not support CFI. It used to, but then it broke, and instead of fixing the issue, they simply stopped using it.
Of course, they also don't use MTE, which Vanadium does on devices supporting it.
Cromite is the successor to Bromite, a now-dead project that changed its licensing to GPLv3 and wouldn't share patches with Vanadium despite taking from it. All in all, I personally see no reason why it's so widely recommended in so called "privacy circles".

https://discuss.grapheneos.org/d/10550-mull-hardened-firefox-security/59

GrapheneOS Cromite makes changes which significantly reduce security, and most of their privacy changes are highly questionable.

https://discuss.grapheneos.org/d/10550-mull-hardened-firefox-security/61

GrapheneOS They do not implement many of the features correctly and take problematic shortcuts. It leads to them having a long list of features which sound useful but which are largely reducing security and not working properly. They incorporate highly problematic third party code from Eyeo full of serious security bugs and full of invasive tracking code. Their technical decisions are not the full picture of what we were referring to though. It's quite relevant that they have no issue with plagiarism, scamming and harassment, even towards people they were taking substantial amounts of code from in the past which they then downplayed. You would be better off using Brave which despite the controversies about cryptocurrency, etc. is far more technically competent and also far more trustworthy than this.

https://discuss.grapheneos.org/d/7141-chromite-vs-vanadium-for-the-average-person/31

final Likewise, the only other browser the project recommends is Brave. It preserves mobile Chromium's security posture while adding additional state partitioning, anti-fingerprinting improvements and the most advanced content filtering engine. Vanadium has greater security enhancements like MTE support in production

To me it looks like using WASM in Vanadium is safer than having V8 disabled in Cromite.

matchboxbananasynergy

mmmm Taking from Vanadium while preventing sharing code the other way is trustworthy behavior to you? The person behind Cromite was with Bromite too, although not the main person there. They can't do that anymore due to Vanadium being licensed GPLv2 now, but they do still have Vanadium patches in their browser, of course.

Being okay with groups that have been hostile to GrapheneOS numerous times in the past is also something we're unlikely to consider trustworthy, too.

mmmm

matchboxbananasynergy Taking from Vanadium while preventing sharing code the other way is trustworthy behavior to you?

I suppose not, from the projects point of view. But from a users point of view I dont see how its particularly relevant. Trustworthy from my point of view, with regards to a browser, is whether they're looking at what I browse, or logging my location, or helping profile me. The 'underworld' of open source coding ethics aren't really my forte, and i guess if i looked that deeply, 'untrustworthy' would take on a new meaning.
But yes I get your point. Thanks for clarifying the reason as to why it should be avoided from the projects point of view.

I dont think it will stop my minimal and particular usage of Cromite.

Edit to add, I am in the habit of having separate browsers for separating things. I have worked that way for years and you cant teach old dogs new tricks. I use several browsers to achieve this. However if I could have multiple instances of vanadium and mulch, I would ditch everything else!

GrapheneOS

TheGodfather Cromite makes changes which significantly reduce security, and most of their privacy changes are highly questionable.

GrapheneOS

mmmm locked They do not implement many of the features correctly and take problematic shortcuts. It leads to them having a long list of features which sound useful but which are largely reducing security and not working properly. They incorporate highly problematic third party code from Eyeo full of serious security bugs and full of invasive tracking code. Their technical decisions are not the full picture of what we were referring to though. It's quite relevant that they have no issue with plagiarism, scamming and harassment, even towards people they were taking substantial amounts of code from in the past which they then downplayed. You would be better off using Brave which despite the controversies about cryptocurrency, etc. is far more technically competent and also far more trustworthy than this.

GrapheneOS

@AlphaElwedritsch Your reply has been removed because you're citing a site full of false marketing claims and misinformation to promote a highly insecure product. Those folks are heavily involved in attacks on the GrapheneOS project through spreading misinformation about it and engaging in harassment targeting our team. Stop promoting it if you want to participate in our community.

Aside from that, GrapheneOS is not a "custom ROM". That's incorrect terminology and should not be used to refer to it.

AlphaElwedritsch

GrapheneOS New to me. Didn't know that. But your statement is OK for me

mmmm

GrapheneOS Thank you. That makes a lot of sense.

wuseman

GrapheneOS aren't most of the issues mitigated in the setup that I wrote though?

The superior option would be Bubblejail but that's hardly widely available or very user friendly.

TheGodfather

GrapheneOS Their seccomp-bpf filter is not a complete sandbox and you are claiming to know their perspective when you do not.

I am referring to their positions in these threads, especially the comments of Gian-Carlo Pascutto (Mozilla):

GrapheneOS Flatpak packages for browsers have weaker internal sandboxing than traditional ones but you're wrong about what the differences are.

The way I understand it is that the native Firefox install has a multi-process architecture with content processes and other processes (like GPU, extension and so on). In the native version the parent process is basically unrestricted and confines the other processes, especially the important content/renderer type processes. It does this through secomp-bpf filters and unprivileged user namespaces
The latter in turn is used to set up different namespaces and chroots, depending on the process type to confine. If a process needs something from outside its own sandbox, it has to use IPC to request it. Because of the multi-process-architecture of FF, the sandbox for each process can be tailored to its process type (e.g. content process).

On the Flatpak version, it is different. Flatpak itself uses namespaces, chroots and secomp-bpf-filter for its own lax sandbox, which encompasses the app as a whole. It uses a secomp-bpf-filter for generic container types on Linux which blocks namespace and chroot creation inside of a flatpak app, because these syscalls would otherwise lead to easy escapes of flatpak's own generic sandbox. But since these syscalls are blocked, FF also can only use secomp-bpf-filters for its own processes and not chroots and namespaces anymore to confine its processes as it does on the non-flatpak version. So the namespaces and chroots around each process got replaced by a more generic flatpak sandbox encompassing the whole app. This leads to a less tailored and thus weaker sandboxing architecture, which neither protects sites, nor stored browser data, nor the system as a whole better than the native version.

Is my explanation correct? @GrapheneOS

GrapheneOS

TheGodfather

I am referring to their positions in these threads, especially the comments of Gian-Carlo Pascutto (Mozilla):

That's not really what it says there. Some of their statements about both Chromium and Firefox are also incorrect. They're clearing aiming to promote Firefox and aren't doing so honestly.

On the Flatpak version, it is different. Flatpak itself uses namespaces, chroots and secomp-bpf-filter for its own lax sandbox, which encompasses the app as a whole. It uses a secomp-bpf-filter for generic container types on Linux which blocks namespace and chroot creation inside of a flatpak app, because these syscalls would otherwise lead to easy escapes of flatpak's own generic sandbox. But since these syscalls are blocked, FF also can only use secomp-bpf-filters for its own processes and not chroots and namespaces anymore to confine its processes as it does on the non-flatpak version. So the namespaces and chroots around each process got replaced by a more generic flatpak sandbox encompassing the whole app. This leads to a less tailored and thus weaker sandboxing architecture, which neither protects sites, nor stored browser data, nor the system as a whole better than the native version.

Firefox doesn't have complete site isolation in any form, whether or not Flatpak is involved. It's also a weaker sandbox. Flatpak weakens it further. You're mixing up several different things.

missing-root

TheGodfather

Very well written, but Firefox simply does not use any filesystem sandboxing in the Flatpak, just seccomp-bpf.

Xtreix

To put it simply, there's no good reason to replace Vanadium with Cromite on GrapheneOS : you'll get the opposite of a better browser.

I tried the desktop version of Cromite on Arch but removed it because the only clear feature for me is disabling JIT and you can do that on Chromium/Chrome by disabling the V8 optimizer, also note that Cromite is almost 100% written in C++ which is a memory insecure language with a ton of attack surface. So I preferred to go back to Chromium via the official repository which works fine for me.

matchboxbananasynergy

Xtreix also note that Cromite is almost 100% written in C++ which is a memory insecure language with a ton of attack surface. So I preferred to go back to Chromium via the official repository which works fine for me.

That's not unique to Cromite.

mmmm

Xtreix my own case in particular, I'm not looking to replace Vanadium with Cromite. But I like to have;

a 'clean' browser to browse in (Vanadium)
a private browser for medical and very private searches (Tor)
a browser to remain logged into web apps in (Mulch)
a browser to shop in (Brave)
a browser to view news and forums in - not logged in or logged in with a pseudo, (Cromite until this thread appeared).

I rename these browsers according to their main occupation.

I have worked like this for years, since before I moved to Graphene. I do it mainly so I keep things separate, and I have always assumed compartmentalisation is a valid choice for security and privacy. I could well be wrong. Aside that though, it helps me keep organised and prevents me from needing to download millions of apps.

« Previous Page Next Page »