N.E.P.T.R

Yes, I understand what GVisor does. Cgroups2 are for isolation of system resources, bit arent even the main sandbox feature used for isolation by Docker. I am pretty sure namespaces significantly more important for these containers’ security.

GVisor helps with one of the main risks in a container setup which is the shared kernel by hosts and guests. I understand it comes with a performance penalty (and I didnt know it was incompatible with SELinux), but that does change my original point that GVisor is a security improvement to default Docker. I understand there is more nuance, even when I wrote my original comment I understood (just like any other security feature) it cant be used in every scenario. I was being intentionally general, and in my second comment I was pretty specific about what it protects against: Kernel vulnerabilities and privilege escalation.

I researched cgroups2 more and I still dont understand why you brought it up in the first place. Cgroups2 and gvisor provide very different security benefits. Cgroups help to keep a system available (lessening the risk DoS attacks) by controlling access to some system resources (io, devices, cpu, memory) and grouping processes of a similar type. It seems rather optimized to solve resource control on a container host. I mentioned gvisor because it is mostly just a drop-in replacement container runtime which doesnt need setup to be used.s

Now for a different container runtime which provides significantly more features (than gvisor) with less downsides (if configured correctly for a specific workload), Sydbox provides syd-oci which id an application kernel runtime which uses a permission config file to create a sandbox, isolating using namespaces, seccomp, landlock, and more. It can sandbox in many different categories (often times leveraging multiple features to provide a multilayer sandbox), you can see the categories at the syd manpage. The biggest downside is that you must really understand what your container application needs otherwise it will prevent it from running. It is a “secure by-default” sandbox which can be softened through config.

I dont really understand what you mean in your last sentence.

My reason for saying GVisor is safer is because it is an application kernel which provides traps and emulates most Linux syscalls in the guest with a far smaller set of syscalls to the host kernel, helping to prevent container escapes and privilege escalation. GVisor also fully drops privileges early into start up (before running any significant logic), helping to prevent privilege escalation.

Cgroups is not a really a security feature (from what I understand). It is about controlling process priority, hierarchy, and resources limiting (among other things). You can not use GVisor with LXC.

Here are some, though they def spammed more communities:

!foss@beehaw.org !privacy@lemmy.dbzer0.com !linux@lemmy.world !linux@lemmy.ml

It was posted in like 5 different communities, some not even close to related (for example 3 Linux communities), some posted twice (eg. the Linux previously mentioned communities). They could have just crossposted it using the feature. Either way it is still a lot of spam. It isnt even that important of news because anyone who cares about this (anti or pro LLM) has already made up their mind and would already have formed an opinion on this feature without a random article.

The UI is proprietary.

In order of most to least secure

VM > Docker+GVisor > Docker/LXC

Docker+GVisor is good middle ground because it provides the guest container with an application kernel in a memory safe language and reduced syscall attack surface to avoid kernel container escapes. Docker/LXC share the kernel with the host.

They disregard the risk from the vendor because you are already using their hardware. The hardware has firmware already included which is proprietary, the hardware itself is proprietary, and hardware effectively runs as root anyways. You should already trust your hardware or you shouldn’t be using it. Linux-libre is a purity test, that is it. It is security theater which actually, definitely, really makes you vulnerable without doing anything meaningful. The only time it makes any sense is if you only use open source hardware.

They disregard the risk from the vendor because you are already using their hardware. The hardware has firmware already included which is proprietary, the hardware itself is proprietary, and hardware effectively runs as root anyways. You should already trust your hardware or you shouldn’t be using it. Linux-libre is a purity test, that is it. It is security theater which actually, definitely, really makes you vulnerable without doing anything meaningful. The only time it makes any sense is if you only use open source hardware.

Being 2 months late to a quarterly patch is still very bad. /e/OS should be avoided.

The embargo on security patches isnt what i am talking about. Once security patches are released, /e/OS takes 1-2 months to patch these vulnerabilities. This isnt because of the embargo but in addition to it! They are by far the worst about this out of any of the alt Android ROMs (2nd worst is iode, at around ~1 month). /e/OS has been terrible about security for years even before all this “Google security patch” nonsense.

There was drama last year because the (or one?) moderator of fosstodon is a fascist.

Just so people known (or a reminder), Grayjay is NOT open source. FUTO is very sus and the cofounder techbro guy (not rossmann) is a fascist wierdo.

/e/OS is terrible for security. They are often 1-2+ monthly behind on monthly Android security patches, leaving their users vulnerable to dozens (i am not exaggerating, often more) of critical and high severity vulnerabilities which are widely exploited. Stay away from that shit.

On fdroid, it reports these anti-features for Xtra

• Depends on not-libre proxy TTV.lol
• Tracks/reports your activity by leaking your IP and Twitch ID to their Russian proxy TTV.lol

Alpine is minimal. That kid would show up in one piece pajamas because it serves the job of pants, shirt, underwear, and sweater+hood.

I would go with (semi)rolling, either openSUSE Tumbleweed/Slowroll or Fedora. I prioritize fast updating distros because they are better for security (many vulnerabilities go unnoticed because the full scope isnt understood and they are deemed normal bugs), and (unlike Windows) updates on Linux are a good thing, bring new features, crash/bug fixes, and optimizations.

Fedora is very popular, has wide software support, and is very stable. openSUSE is also still pretty popular, (even its rolling edition) is quite stable as well, has good software support, and YaST allows you to do graphical administration on your system. Both take security seriously and use SELinux for security policies.

If you care about security, use Brace for automatic system hardening. It has been developed for years by the former DivestOS dev Tavi, supporting many distros.

Windows has plenty of things to complain about. This type of feature is not one of them.

Example: https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet

Also, in this article some explanation of why nothing should be in pid1 other than what is truly necessary, and any example pid1 program written in C under the heading “So how should init be done right?”

Are these “other features” hard dependent on systemd? If yes, how are they modular (or portable)? “My program can be used on any system with a couple of small dependencies: Linux kernel, glibc, and the systemd Kernel” /j

There are some attempts to use systemd tools independent for it, like elogind and eudev, but see what I mean. Hard forks (with major rewrites) are required because these tools heavily depend on systemd, which fine I understand having dependency, but you cant just use part of systemd since it is to tangled together. It would be nice if mire of systemd code was available as separate libraries so you could further reduce attack surface by building a significantly slimmed version of systemd+feature. I am unsure if you meant modular as in “you can choose to enable them” or as in “you can build without them” or both.

Also, I never claimed systemd ran everything under pid1, just plenty more then the should be, like init plus service manager (and more), not every single systemd tool because that would be beyond stupid and systemd isnt made by idiots.

Compromising/crashing pid1 (which becomes increasing likely when the program is massive) takes down the entire system. pid1 should only be the initial init (which should be as small as possible, basically a stub) and start the service manager as a separate pid. This allows the system to gracefully recover by restarting other processes without fully locking-up/crashing. It is a bad practice.