All I do is have agetty --autologin root tty2 linux run as a service. It launches on startup, and I just hit CTRL + ALT + F2 if I ever need a root shell.

All its doing is just auto logging-in as root on TTY2.

From what I’ve read, no. Though it doesn’t solve the fundamental problem of a root process handling untrusted input from a regular user.

The TTY method is IMO better as it ties privileges to a piece of physical hardware, bypassing the complexities of userspace elevation of privileges.

The nosuid mount option disables this behavior per mount. Just be sure you don’t use suid binaries.

Example: sudo or doas. I replaced those with switching to a tty with an already open root account on startup. Generally faster and (for me) more secure (you need physical access to get to the tty).

We’re using the definition differently. There is nothing left to discuss.

Miranda is required by law

Irrelevant to the point. I was pointing out the value proposition. Certain things exist for a minority of people. I view the 'reason why" as valuable, even if only a minority care about it.

They don’t have to explain anything to you

Correct. We wont do business if one cannot give an explanation. One can write in the privacy policy that they collect all sorts of private information, but the kicker, for me, is often why.

The vast majority of people who run into the Anubis setup will have no fucking clue what any of it means, nor give a shit about it. They just want to get to the content.

One doesn’t have to care about the Miranda warning, but its still read off to someone in case they do.

From my experience a user account usually needs to be in the “wheel” group to elevate privileges through sudo. So try that.

Its their responsibility to make clear the reason they require it.

Something like Anubis does it well by adding a “Why am I seeing this?” section to their JavaScript challenge.

You are seeing this because the administrator …

Anubis is a compromise. Anubis uses a Proof-of-Work scheme in …

Ultimately, this is a hack whose real purpose is to give a “good enough” placeholder solution so that more time can be spent on …

Please note that Anubis requires the use of modern JavaScript features that plugins like …

Sadly, you must enable JavaScript to get past this challenge. This is required because AI companies have …

If you require something, such as an account, to view the content. Simply add why.

Simply: Do the protections against someone taking your computer and installing a malicious program before/as your OS, or a program that has attained root on your machine and installs itself before/as your OS, matter enough to you to justify the increased risk of being locked out of your machine and the effort to set it up and understand it.

If you don’t understand and don’t want to put in the effort to, then my advice would be to leave it off. Its simple, and the likelihood it saves you is probably very miniscule.

…and this is the primary reason they cannot be supported directly by Graphene.

This is phrased like a technical boundary. They are not supported because Graphene chooses not to support them. Not to say it would be easy, but they are making a choice to solely use Google’s hardware.

They don’t have to.

My biggest gripe with flatpak is the fact it isn’t sandboxed properly by default.

I’m not referring to vendor-given privileges. Every flatpak, unless explicitly ran with the –sandbox option, has a hole in the sandbox to communicate with the portal. Even if you try to use flatseal to disallow it, it will still be silently allowed.

This leads to a false sense of security. A notable issue I found is if you disallow network access to a flatpak, it can still talk to the portal and tell it to open a link in your browser. This allows it to communicate back to a server through your browser even though you disallowed it. Very terrible.

Security should to be dead easy and difficult to mess up. The countless threads I’ve read on flatpak tell me the communication about flatpak’s actual security has been quite terrible, and so it doesn’t fit this category.

Ignore the downer replying to you. If you found something that works well for you, then great!

… Alpine is designed to be friendly to corporations who want to lock down their devices and prevent you from modifying them.

“Designed to” assumes intent. Alpine is absolutely designed to be Small, Simple, and Secure. Using busybox instead of the GNU coreutils is a means to this end. Using musl instead of glibc is a means to this end.

On the about page they list why they use these tools. The licensing is not listed at all.