I have learned that the setting unprivileged_userns_clone is enabled on Zorin OS.
This is not shocking - since Ubuntu defaults to it enabled and has for years.
I believe that this is due to it being conducive to using Containerized apps (Snap, Flatpak) and FakeRoot.
I noticed, while searching it on my computer, that it appears in the SteamWebHelper.sh file - it checks if it is enabled or disabled in order to determine whether it can or cannot launch Sandbox.
However, having it enabled also can open up security vulnerabilities:
And I would also like to know. I am hitting this learning curve the same as you - I only recently discovered that it is preset to enabled on Zorin OS (And on Ubuntu in general).
Recently, Debian, who always kept it preset to disabled for security reasons, gave in and started setting it as enabled. They released a public statement:
"The previous Debian default was to restrict this feature to processes running as root, because it exposed more security issues in the kernel. However, as the implementation of this feature has matured, we are now confident that the risk of enabling it is outweighed by the security benefits it provides."
Gathering a consensus on the web is... not so easy.
As I pointed out in the O.P., there is a reasonable element of doubt in regards to those that promote the security concerns as "not so very serious...."
It may be that the security concerns are not so serious. But given the above bias and doubt as well as a lengthy list of Security Vulnerabilities, it becomes an extraordinary claim to say they are not.
And extraordinary claims require extraordinary evidence.
I also want to test how well Steam w/Proton works with the unprivileged user namespaces disabled.
Does VirtualBox work with it disabled?
And so on.
Yep, found Sequoia and Looney Tunables - of which, I'm pretty sure both have to be performed locally and, can escape VM containers.. May set up a lab and try it out.
I'm seeing more and more exploits coming through with Linux.. not cool, man! There are mitigations; changing a 1 to a 0 to disable the vuln. may be the only way right now, without a patch.. Since I'm the only user on my machine, I'm not exactly worried about it - but, patches will come, I'm sure. Just like the Downfall vulnerability.
I'm just wondering - at any possibility.. if this was intentional
I am not sure I understand this. Are you referring to the decision to enable unprivileged user namespaces? Because that was 100% intentional and described as such when the decision was made.
As this being a vulnerability - just questioning, if this is a risk, why it wasn't caught before release? And intentionally, like with Internet Explorer - here, very dated - probably not but, have seen these kinds of things in the past. Not exactly an intentional, as in purposefully malicious, piece of code that could be used for bad. Rather more easily exploitable vulnerability that slips through - much like with Sequoia or Looney Tunables. And yes I see why the decision was made as well, was following along with the CVE's and some other sources.
Just odd is all. Still surprised to see that more and more are coming out for Linux!
I have been reading up on this. And I have reached certain conclusions.
If I post sources, this post will be a mile long. So, I am only going to post my thoughts and conclusions.
This is a classic Catch-22 situation.
This process user namespaces was developed as a sysctl knob for SystemD by Eric Biederman.
Biedermans commentary on it shows a lot of bias in favor of the programming. He also states that it was never intended for Desktop Systems (which explains a lot of the holes). But, since it is fully entangled with the cobweb SystemD - it ends up included on Desktop systems.
Without enabling unprivileged user namespaces, containers, sandboxes and virtual environments cannot be run. This artificially creates Dependency on SystemD and on that sysctl knob.
As an example, the Chrome Browser (and therefor, likely its derivatives like Brave Browser) rely on using a Sandbox for security reasons. Without enabling the exploitable Unprivileged user namespaces, the browser cannot run. Enabling it creates that security hole.
So... your only other option is to run the browser without the sandbox - and this creates a security hole.
Catch-22
So the general consensus in GnuLinux has become that enabling Unprivileged user namespaces closes the security hole that would be opened by running the browser without sandboxing. The Browser seems the more glaring security hole. In this, they can spin the claim to be that enabling Unprivileged user namespaces "makes a more secure user experience." Note the quotation marks, there...
This also means that those who seem to be downplaying the security risks of having Unprivileged user namespaces enabled are doing just exactly that. Downplaying it.
"Ok... fine... so why don't 'they' just Fix It?"
Because 'they' cannot just fix it. It is a tangled mess of layers of programming performed by many different people. It would require a concerted and coordinated effort - including among experts of Systemd (Who are few in number at best and those who exist are... shall we say... ornery...)
sigh
The result comes down to "Pick your poison."
"Fine! Can I just disable it?"
Yes. But if you do, a bunch of apps may no longer work including VM's, browsers, Snaps and Flatpaks and many others. This choice has been made for you without actively wresting control from your fingertips but instead by painting you into a corner.
This has no easy solution or workaround at this time.
I would argue that there could be a workaround if Team Zorin ditched systemd for a simple "init", which coined the unix phrase, do one thing only, and do it well. There's a funny YouTube video " Devuan is born" which I posted in the lounge's humour thread.
As it is - currently - we already observe users stating that Zorin OS is "outdated" because it doesn't bring the latest and greatest.
Not the majority.
But it is selective pressure.
The ZorinGroup specifically needs a base that is reliable, stable and well supported. This does not mean that they like it. Or that they agree with all of it.
It means that given the options available, they pick and choose their poison. And it took me a bit of time to realize this.
The problem does not start with our distro. It started years ago when the adoption of SystemD became a Political Issue in GnuLinux instead of a Practical Issue.
When SystemD was endorsed not by its merit, but by who you know.
Now, it is an inter-connected jumble relying on dozens of unaffiliated developers.
It's like if you go to your autoparts store and request a specific part - but the store says they cannot fill the order because the Supplier made decisions outside of that stores control.
The Supplier claims he made his decisions based on manufacturer decisions outside of his control.
The manufacturer claims supply chain disruption (illusory) and Logistics issues resulted in the decisions they made, when in reality it was governed by Greed which they will simply not publicly admit to.
What bothers me the most about this issue is not the exploitable security holes. It is that the Users were not kept well-informed on the issue and educated about what it all means. It came back down to CYA on Beiderman and Debian and Canonicals part.
Hush it - instead of letting the users make an informed decision of their own.
It came back down to those at the top looking down on and discounting the intelligence of the users. Just like Microsoft does. Just like Apple does.
The security holes in user namespaces are exploitable most commonly by use of Direct Access - whereas the Browser can be much more easily hijacked remotely.
I must agree with the decision of enabling it by default not because it is the right decision but because standing in the mess we are in, it is the safer of two evils.
The ZorinGroup cannot just change the Zorin OS base without frightening a large number of users. Not because the choice would be "wrong" but because the users would not know what that choice entails. It would give the appearance of a lack of stability.
This makes Zorin OS beholden to the choices that other developers make, however.
It becomes our role to educate users, provide not just a means of learning, but the motive to do so. To help users recognize their own merit and intelligence and to use it instead of following route step that they are not supposed to be involved.
Because as it is right now - the users being shaken by a change at the top is as much the users fault as it is the fault of those at the top. We are responsible to be willing to learn. That onus is on us.
Containers and Sandboxed apps are the "big solution" for having apps that are "the latest and greatest" or are secured and hardened. Flatpak and Snap being promoted as the Big Babies of those at the top. Just shut up and take 'em.
Banking apps. Cryptocurrency apps. Or Virtual Machines (Lintian is one). Browsers that need to create a secure workspace for certain websites.
Users demands (even users who have been misled by developer claims) are as much at fault as are the developers that allowed EGO to rule their logic and choices instead of reverting their work when it came out broken.
I need to look at the Sequoia one as well - same attack vector. Also same situation as with the Downfall attacks - requires physical access to be carried out. I wasn't able to find any instances in the wild but, that doesn't mean it's not happened yet.. I would list that under the 'known unknowns' column - for now. And as publicity gathers, I'm sure there will be some that actually try carrying this out.. Like always!
Absolutely interested to see how this will be mitigated.
I truly wish I did.
I have struggled for many years to learn how to express myself at least adequately rather than poorly. Don't know if I can aim so high as to try to do it well.
As a FOSS user, I want to be part of the community and contribute as much as possible, not just consume what the developers deliver. Therefore, I do not support projects that refuse to involve users. However, I have seen many lazy users who allow such projects, and many selfish users who just blame the developers and do not contribute.
Just as with freedom comes responsibility, so it should be with FOSS. It is not enough to have a formality such as open source or adopt a free licence.
I PM'd AZorin about Storm's post and was assured that they make use of Ubuntu's security patches. Usually, a fix comes down the line before the researchers make their findings public. There was one delay, outside the kernel and outside of Canonical's hands, that being Polkit. Having browsed information on which is more secure, GNU/Linux or that other OS, and GNU/Linux came out on top because:
a. it is (in terms of its ethos) community driven. [But this excludes Red Hat and their former employee Lennart Poettinger who compiled systemd (and the equally problematical PulseAudio which is now used in all automotive hardware)]
b. Patches are more forthcoming more quickly to fix security issues from hours to a few days compared with a closed source OS.
Historically there have been exceptions. There was a major security flaw in the Linux kernel for several years (qcow?), but even that could not beat Microsoft's major flaw that existed for more years than that of the Linux kernel, so Linux [kernel] is generally ahead of the game.
Red Hat has always made it's aim to be the M$ of the GNU/Linux world; now that it is owned by IBM one can only wonder what is coming round the corner.
I found an old web page on how to add SysV Init to earlier versions of Ubuntu, but that was dependent on having access to Canonical's version of it, Upstart.
It's turning more into a "who done it" now - which no one I can see is placing blame since Aravisian pointed out where the fault lies..
One thing I'm trying to get out is that this, like the Downfall attack, has to be done locally; physical access to the machine - and you have to be a target. From a red team point of view - yep, not very good. From a blue team point of view - yep, still not good but, likely not to happen with someone perusing around the net looking at cat pictures Especially those that run VPN - which is now, too, able to be penetrated. The likeliness of that happening? not very.. And that is absolutely excluding big companies, banks, server farms, etc. because the common person isn't running a whole companies NAS, or a banks transcripts, or CC transactions.. meow!
And of course the Ubuntu patches will be utilized; I'd expect nothing less
This is actually Eric Biedermans point when he posits that the sysctl knob he wrote was not intended for Desktops.
Yes and I also reached the same conclusion.
Having unprivileged namespaces enabled is a primary vector for Local, not remote attacks.
Whereas an unsandboxed browser has threats that can operate remotely. For users using banking apps, you can see how the devs had to choose what to pay attention to.
Being a red teamer myself, I like seeing how that stuff goes down - why I posted the SecCrowd link I just wish I knew about this one before my final lol
Still wouldn't mind setting up a lab for myself though..
Especially those that run VPN - which is now, too, able to be penetrated. The likeliness of that happening? 
not very.. And that is absolutely excluding big companies, banks, server farms, etc. because the common person isn't running a whole companies NAS, or a banks transcripts, or CC transactions.. meow!
I just wish I knew about this one before my final lol