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.

A threat model in which you don’t trust the Linux Foundation and volunteers but do trust Microsoft.

Its all about what you want to protect. If a security breach is worse for you on Linux than it is on Windows because of which party has the data, then for you, Windows might be more secure.

Some people get confused because they think there is some objective measurable security rating one can apply to a system for every person. There isn’t. We may use the same systems but have different threat models and thus rate the security different.

Privilege escalations always have to be granted by an upper-privilege process to a lower-privilege process.

There is one general way this happens.

Ex: root opens up a line of communication between it and a user, the user sends input to root, root mishandles it, it causes undesired behavior within the root process and can lead to bad things happening.

All privilege escalation is two different privilege levels having some form of interaction. Crossing the security boundary. If you wish to limit this, you need to find the parts of the system that cross that boundary, like sudo[1], and remove those from your system.

[1]: sudo is an SUID binary. That means, when you run it, it runs as root. This is a problem, because you as a process have some influence on code that executes within the program (code running as root).

secureblue is about as secure as Linux can get…

Unless you have an unusual threat model, this statement is utter nonsense. I can run a kconfig stripped kernel with zero kernel modules and one userspace process that is completely audited and trusted, without the ability to spawn even other processes or talk to network (because the kernel lacks support for the IP stack).

Secureblue might offer something significant when compared to other popular and easily usable tools, but if you compare it to the theoretical limit of Linux security, its not even comparable.

I examined Secureblue’s kernel parameters and turned multiple of them off because some were mitigations for something that was unnecessary. IE: The kernel would make the analysis that your hardware is not affected by a vulnerability, and thus there is no need to enable a specific mitigation. But they would override this and force the mitigation, so you take a performance hit, for what I understand to be, no security gain. Not sure why they did that, a mistake? Or did they simply not trust the kernel’s analysis for some reason? Who knows.

Is desktop linux more insecure than Windows?

This is an impossible question to answer without more information. Depends on your threat model, how you use the computer, your distro, etc.

…if someone nefarious gets to the point they can read this stuff then they’ll already be able to record your screen, log keystrokes, etc.

No screenshots -> less data. Less data -> lower breach severity.

(Unless you have an unusual threat model)

All this can be gutted by an advanced user.

Talk is cheap. Show me the code.

…the government is absolutely a threat to you.

I don’t see how this supports your previous claim of: “If you don’t have privacy from the government, you don’t have privacy.”

If you don’t have privacy from the government, you don’t have privacy.

Privacy refers to more than just privacy regarding the government.

Your threat model and situation might mean that if the government knows something, its as bad as if every single person knows it.

But this isn’t for everyone.

Here is a page for screen lockers.

The censorship being referred to here is a legally defined term…

There is no such mention by OP about the legal definition.

Censorship in all the dictionaries I see don’t require it to be a government that is censoring for it to be called “censorship”.

Someone attempting to hinder someone else’s ability to reach certain information is engaging in censorship.

Security is much more effective and adopted when it is simple. My understanding is that SELinux is not.

This means not only will fewer people use it and more people turn it off if something doesn’t work, it means more people are at risk of misconfiguring their system to allow something they didn’t intend to.

This is somewhat mitigated from the fact that, from my experience, Linux Security Modules cant ever make you less secure than without it. But it still can provide a false sense of security if you misconfigure it.

Here is a good article showing what I am referring to, and providing a solid security tool: BSD pledge/unveil on Linux.

Depends on the environment surrounding the door, as well as the environment surrounding the computer.

Some people simply care less about their computer security. The debate stops there. Security operates on a foundation of what you want to secure.

By comparing two environments of someone’s life you know little about, you are commenting from ignorance.

True.

Though, you are probably going to have a much easier time implementing a change to your code that is present in a company’s published code, than you would trying to reverse-engineer a binary.

Sharing of the code I would consider “giving back” in it of itself.

It can be done if you mess with the initramfs.

The kernel starts everything else by unpacking an archive containing a minimal environment to set stuff up for later. Such as loading needed kernel modules, decrypting your drive, etc. It then launches, by default, the /init program (mines a shell script).

That program is PID 1. If it dies, your kernel will panic.

After it finishes setup, it execs your actual /sbin/init. These means it dies, and that program (systemd, openrc, dinit, runit, etc) becomes PID 1. If an issue happens, both could fail to execute and the kernel will loop forever.

Linus already has a backup. Its Greg Kroah-Hartman.