linux-hardened VS systemd

Glossing over their hardening guide, we notice that the kernel-hardened package is mentioned. This is a fork of what once was the kernel of GrapheneOS. While this hardened kernel can be used on a variety of distros, unfortunately this doesn't apply to Fedora Silverblue. Furthermore, I haven't seen any mention of the hardened kernel being used on openSUSE Tumbleweed. Therefore I see no reason to believe that this is possible on openSUSE Aeon either. Though, I'd love to be corrected on this!

Here's the GitHub page for the linux-hardened package in the official Arch repos. You will find that lots of changes come from GrapheneOS. "Forked from GrapheneOS" is in tiny, tiny text near the top-left of the web page underneath the project name.

Here is the source code for the hardened Linux kernel.

so that we can use it liberally in CLI) > **Additionally, here's a 'building from the source section** - https://github.com/firecracker-microvm/firecracker/blob/main/docs/getting-started.md#building-from-source ### Running Firecracker > "*In production, Firecracker is designed to be run securely, inside an execution jail, carefully set up by the jailer binary. This is how our integration test suite does it. However, if you just want to see Firecracker booting up a guest Linux machine, you can do that as well.*" 1. We need to first obtain an "uncompressed Linux kernel binary, and an ext4 file system image (to use as rootfs)" ; great, these are two things that we need to seek out before we move forward in our 'adventure' (*this really feels like a "quest" of some sort, like the ones that they forced you to play on Runescape back in the days*) **How to Decompress Linux Kernel** (explicit instructions to be honest here) - https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-5.html **Linux-Hardened Kernel** - https://github.com/anthraxx/linux-hardened (this is something that they're all still actively working on at this very point in time) They also say that we need an 'ext4 file system image' (where do we obtain this from?) - found it **Full Guide on How to Create an EXT4 filesystem image here** -https://fabianlee.org/2020/01/13/linux-mounting-a-loopback-ext4-xfs-filesystem-to-isolate-or-enforce-storage-limits/ Assuming that the above has been handled, the directions insist that we create two separate shell prompts, (one to run Firecracker, and another one to control it [by writing to the API socket]; both shells have to run "in the same directory where the firecracker binary was placed") ^^ What? - This is a pain in the ass because this is something that they should've mentioned earlier (obv. everyone is going to move a binary where the rest of their binaries go ; and you're not going to just load up some random project to be used in that manner) - Not even sure what the end goal of opening up an API socket here would really be But fuck it, let's just assume that we play ball and we adhere to all of these (additional) steps that we're being put through (just for the setup up this virtualization tool!). ### Following Through on the Next Steps 1. Ensuring that Firecracker can create its own API ``` bash rm -f /tmp/firecracker.socket

Officially supported kernels Community support on forum and bug reporting is available for officially supported kernels. Stable — Vanilla Linux kernel and modules, with a few patches applied. https://www.kernel.org/ || linux Hardened — A security-focused Linux kernel applying a set of hardening patches to mitigate kernel and userspace exploits. It also enables more upstream kernel hardening features than linux. https://github.com/anthraxx/linux-hardened || linux-hardened Longterm — Long-term support (LTS) Linux kernel and modules. https://www.kernel.org/ || linux-lts Zen Kernel — Result of a collaborative effort of kernel hackers to provide the best Linux kernel possible for everyday systems. Some more details can be found on https://liquorix.net (which provides kernel binaries based on Zen for Debian). https://github.com/zen-kernel/zen-kernel || linux-zen

Overall those patches do protect you in a lot of cases. Per default upstream features are chose to honor security first. Furthermore patches do frequently protect against upstream failures and vulnerabilities. One of the latest examples is CVE-2022-1729 https://seclists.org/oss-sec/2022/q2/122 a local privilege vulnerability that linux-hardened simply protects since before day 0: https://github.com/anthraxx/linux-hardened/commit/4dd6bdf3b079ef73e597661ee961d225bfccbe2a On top the approach in several places of fail-early instead of potentially continuing with known corruption or certain use-after-free regularly uncovers problems that get fixed upstream and where the vanilla kernels just keep on running, which include exploitable problems. One example of a faulty very recent commit that has been bisected and fixed because of linux-hardened: https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next&id=acde4003efc16480375543638484d8f13f2e99a3

Those two don't protect the kernel itself from "misuse". To do that, there are ways like kernel hardening 3, using hardened kernel 4 5.

No, the OP was not sent any harassment, the OP _did_ the harassment as it can be seen in the tweets. I mean, they are right there, just click on the links you shared. One of the OP's followers even openly called for the assassination of the project maintainer, and you have the galls to defend him? This is truly deranged stuff.

And again, there is no "vulnerability", there is simply a person that doesn't know how Linux works and has learned something new. Which again it's fine, nobody knows everything and we all learn new things everyday, it's just that normal and sensible people don't use that to make grand claims on social media and start harassment campaigns culminating in death threats.

Professional security researchers responsibly report real issues using the appropriate channels, such as defined at: https://github.com/systemd/systemd/security/policy this is not the work of a researcher, this is a grifter looking for self-promotion on social media.

> 3. even `adduser` will not allow it by default

5. useradd does allow it (as noted in a comment). 6. Local users are not the only source, there things like LDAP and AD.

7. POSIX allows it:

* https://github.com/systemd/systemd/issues/6237#issuecomment-...

> I for one love to type out 13 extra characters

FWIW, systemd is normally pretty good at providing autocomplete suggestions, so even if you don't want to set up an alias you'll probably just have to type `--b ` to set it.

> I wonder what random ASCII escape sequences we can send.

According to the man page source[0]:

> The color specified should be an ANSI X3.64 SGR background color, i.e. strings such as `40`, `41`, …, `47`, `48;2;…`, `48;5;…`

and a link to the relevant Wikipedia page[1]. Given systemd's generally decent track record wrt defects and security issues, and the simplicity of valid colour values, I expect there's a fairly robust parameter verifier in there.

In fact, given the focus on starting the elevated command in a highly controlled environment, I'd expect the colour codes to be output to the originating terminal, not forwarded to the secure pty. That way, the only thing malformed escapes can affect is your own process, which you already have full control over anyway.

(Happy to be shown if that's a mistaken expectation though.)

[0] https://github.com/systemd/systemd/blob/main/man/run0.xml

[1] https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_G...

bash & zsh are supported by upstream: https://github.com/systemd/systemd/tree/main/shell-completio...

the right person to replace sudo, not: https://github.com/systemd/systemd/issues/6237

PS: https://pwnies.com/systemd-bugs/

https://github.com/systemd/systemd/issues/32028#issuecomment...

There are some very compelling arguments made there if you care to read them

Maybe it was because you weren't pointing out anything new?

There was a pull request to stop linking libzma to systemd before the attack even took place

https://github.com/systemd/systemd/pull/31550

This was likely one of many things that pushed the attackers to work faster, and forced them into making mistakes.

The PR for changing compression libraries to use dlopen() was opened several weeks before the xz-utils backdoor was revealed.

https://github.com/systemd/systemd/pull/31550