You can do what’s called dual licensing, where you make contributes sign an agreement where they give up their code to the org so the org could take it proprietary.
Part of the controversy over Ubuntu’s changes to LXD was the change to this dual licensing setup from a permissive license.
This worked for me. Thankfully, I didn’t have a hard crash during an update, so my system proceeded to boot normally.
The craziest part is that I didn’t google this. My computer crashed, I rebooted it via magic sysrq keys, and then booted to an error.
I went on Lemmy on my phone out of frustration and by sheer chance one of the first things I saw was a solution.
I think I’m getting the same error as OP, and booting from a snapshot sadly does not work.
No, because they don’t deviate enough from arch to avoid issues with breakages on updates. Just recently on lemmy someone was wondering why all their vlc plugins were uninstalled. Easy fix for someone who knows how to use pacman, but that and similar incidents make cachyos not really a “just works” system.
Does that happen often? I had, apparently incorrectly, assumed those things were more or less fire and forget.
Bootloaders are also software affected by vulnerabilities (CVE’s). But this comment did make me curious. Do the CVE’s that affect grub, would a person of threat model/usecase 1 in my comment above care about them?
Many of them do indeed seem to non issues. From the list here.
Grub CVE’s requiring the config file to be malicious, like this one are pretty much non issues. The config file is encrypted, in my setup at least (but again, not the default. Also idk if the config file is signed/verified).
I think this one is somewhat concerning. USB devices plugged in could corrupt grub.
Someone could possibly do something similar with hard drives, replacing the one in the system. The big theoretical vulnerability I am worried about is someone crafting a partition in such a way that it does RCE through Grub. Or maybe’s it’s already happened, my research isn’t that deep. But with such a vulnerability, someone could shrink the EFI partition and then put another partition there, that grub reads, and then the code execution exploit happens.
But honestly, if someone could replace/modify hard drives, or add/remove USB devices, what if they just replace your entire system motherboard with a malicious one? This is very difficult to defend against, but you could check for it happening by having your motherboard be password protected, and you always log into your motherboard whenever you boot to make sure the password is the same. (Although perhaps someone could copy over the hashes (at least I am assuming the passwords are hashed) from one motherboard to another).
But if something like that is in your threat model, it’s important to note that ethernet, and many other firmware is proprietary (meaning you cannot audit or modify the code), and also has what’s called “DMA” — direct memory access. It can read and write to the Linux kernel with permissions higher than root. So if I have access to your device, I could replace your wifi card with a malicious one that modifies stuff after you boot or does any other things.
What you are supposed to do is prevent tampering in the first place, or for a much cheaper cost, have “tamper evident protection”, things that inform you if the system was tampered with. Stickers over the screws are an easy and cheap example…
But DefCon has a village dedicated to breaking tamper evident protection. Lol.
I think if your adversary is a nationstate, secure boot usecase 1 is simply broken and doesn’t work. It’s too easy to replace any of the physical components with malicious one’s for them, because there is no verification of those. I think Secure Boot usecase 1 is for protecting against corporate espionage in mid to high tier corpos. Corporations also tend to give people devices, and they can ensure that those devices have tamper evidence/tamper resistance on top of secure boot. Of course I think a nationstate can get through them, but I don’t think it’s included in the threat model.
Nationstates can easily break the system of secure boot, and probably have methods in addition to or separate from secure boot for protecting themselves.
Wait what, that just seems like home directory encryption with extra steps 🤦 I guess I’ll go back to Veracrypt then.
Performance on LUKS might be better since LUKS is a first class citizen. But maybe performance with veracrypt is better since only the home directory is encrypted. I tried duckduckgo but the top results were AI slop with no benchmarks so I’m not gonna bother doing further research.
Openwrt seems to be more popular
but wouldn’t only the bootloader need to be signed
So the bootloader also gets updated, and new versions of the bootloader need to get signed. So if the BIOS is responsible for signing the bootloader, then how does the operating system update the bootloader?
To my understanding a tamper-proof system already assumes full disk-encryption anyway
Kinda. The problem here, IMO, is that Secure boot conflates two usecases/threat models into one:
The second person does not use full disk encryption, or care about physical security at all, really (because they physically lock up the server racks).
What happens in this setup is that the bootloader checks the kernel’s signature, and the kernel checks the driver’s signature… and they enable this feature depending on whether or not the secure boot EFI motherboard variable is enabled. So this feature isn’t actually tied to the motherboard’s ability to verify the bootloader. For example, grub has it’s own signature verification that can be enabled seperately.
The first person does not have malware in their system in their threat model. So they can enable full disk encryption, and then they don’t care about the kernel and drivers being signed.
EXCEPT THEY ACTUALLY DO BECAUSE NOBODY DOES THE SETUP WHERE THE KERNELS AND DRIVERS ARE ENCRYPTED BY DEFAULT.
You must explicitly ask for this setup from the Linux distro installers (at least, all the one’s I’ve used). By default, /boot, where the kernel and drivers are stored, is stored unencrypted in another external partition, and not in the LUKS encrypted partition.
What I do, is I have /boot/efi be the external EFI partiion. /boot/efi is where the bootloader is installed, and the kernels are stored in /boot, which is located on my encrypted BTRFS partition. The grub bootloader is the only unencrypted part of my system, like the setup you suggested. But I had to ask for this by changing the partitioning scheme on CachyOS, and on other distros I used before this one.
Very interestingly about this setup, is that grub cannot see the config it needs to boot. It guesses at which disk it should decrypt, and if I have a usb drive plugged in, it guesses wrong and my system won’t boot.
Continuing, the problem with setups like this is that in order to verify the bootloader, you must have secure boot enabled. Grub will then read this EFI configuration, and attempt to verify the kernels and drivers. As far as I can tell, there is no way to disable this other than changing the source code or binary patching grub.
I have a blog post where I explored this: https://moonpiedumplings.github.io/playground/arch-secureboot/index.html
So this means that even in setups where everything is encrypted except grub, you still have to sign the kernels and drivers in order to have a bootable system (unless you patch grub).
I eventually decided that this wasn’t worth it, and gave up on secure boot for now.
Ubunti used to have a a tool that did something similar, but that tool is dead now.
I’m very happy to see a successor.
I consider it a lesser evil to use curl | bash once to install Nix and then get the latest version of packages like rustup and deno than to use curl | bash twice or more to install software on their own (in addition to my opposition to developers installing software on users machines).
And again, cycling all the way back around to what I said in the earlier comments, you still have not provided an example of bash scripts you would like packaged that do stuff other than installing software. You talk about wanting a general repo of scripts, and I have also expressed my concerns about that, and the problems with losing it’s portability when you need an extra tool instead of bash and curl/wget.
We are just rehashing the same points.
In my opinion, you are starting too big. It’s better to start smaller. Many locations have a “Linux User Group” or “hackerspace” or a “Computing Club”. (Those are exact keywords you can try searching for).
And often times, those organizations host their own small set of services for their members. For example, when I was searching for help on how to set up something with Kubernetes, I came across this blog, where the blog author hosts services for their “Chaos Computing Club”, like proxmox, nextcloud (has a calendar app), matrix, and forgejo.
Instead of trying to spin up a set of services for the whole “FOSS Community” start smaller and just host for your local groups. Maybe your local hackerspace already hosts these services.
To find local meetups, I checked out https://meetup.com/, which has a lot.
As for me personally, I am trying to put together services for my Cybersecurity club at my school, right now I have centralized identity, and virtual machine hosting for members to access and play with, but I want to also host extra services like the stuff you mentioned, because the reasons why you want them are good.
On my blog, I discuss my plans and steps: https://moonpiedumplings.github.io/projects/build-server-6/
I think creating a “FOSS hub” overall is a really really big challenge because all of these groups that make up the FOSS world have a heterogeneous set of overall interests, and an even more heterogeneous set of users.
A simple example is the language barrier. Fun fact: There exist alternatives to apps that primarily have English as their first language, but in other languages first, centering around the communities those languages are used in. For example, the opendesk docs are in German first. Of course, there are English docs for things like engagement, but the problem is that —
For something like a FOSS hub, user engagement is critical, and one of the best ways to have engaged users is dogfooding, where users contribute back to this software they use. But with software that treats one language or another as a first class citizen, there is becomes a bump, when users want to dogfood.
The other problem is that the users themselves have different needs and wants. One user or set of users hates email and never wants to touch it. Another wants to exclusively use plain email for everything, including as an alternative to code forges, discussion platforms, and scheduling systems. One set of users prefers discord, the others prefer irc. They meet in the middle on matrix, but this other set of users hates matrix due to being VC funded and it’s just a clusterfuck.
You cannot make both groups of users happy. When you try to please everybody, you end up pleasing nobody.
What you can do, however, is catch the needs of your local groups and slowly expand from there. I think a FOSS Hub is possible, but I think trying to start it as a foss hub is bound for failure because the scope is too large.
I think the closest thing right now is disroot, which hosts a lot of services, but again Disroot uses XMPP whereas some people may prefer Matrix for this usecase, and plenty of other nitpicks.
I find this comparison unfair becuase k3s is a much more batteries included distro than the others, coming with an ingress controller (traefik) and a few other services not in talos or k0s.
But I do think Talos will end up the lighest overall because Talos is not just a k8s distro, but also a extremely stripped down linux distro. They don’t use systemd to start k8s, they have their own tiny init system.
It should be noted that Sidero Labs is the creator of Talos Linux, which another commenter pointed out.
I find this comparison unfair becuase k3s is a much more batteries included distro than the others, coming with an ingress controller (traefik) and a few other services not in talos or k0s.
But I do think Talos will end up the lighest overall because Talos is not just a k8s distro, but also a extremely stripped down linux distro. They don’t use systemd to start k8s, they have their own tiny init system.
It should be noted that Sidero Labs is the creator of Talos Linux.
Apologies for the second comment, but I do want to clarify that I find curl | bash okay when they are used to install a package manager or platform that can install more software. (in more than one programming language, though).
I find that acceptable because:
curl | bash.There are very few software of these exceptions, however.
dev can keep using bash
I don’t want “devs to keep using bash”. My security problems are with the developer distributions of these softwares themselves, rather than bash. Even if developers offered a rust binary as an installer (or a setup.exe), I would still be miffed and disappointed with them for doing things like vendoring CVE’s into their software!
Simply having this discussion brings attention to the issue, and to alternatives for getting packages onto the users machine, thereby increasing their security. There’s a reason why it’s a hot topic whenever it’s brought up.
don’t understand why you treat it as all or nothing problem. It’s clearly not
There are clear alternatives to using developer install scripts to install software though: package managers
And they are not using package managers because clearly they don’t meet their needs.
Developers incorrectly believe that they need to vendor dependencies or control the way software is installed, which package managers of distros do not offer them. So they don’t mention the way that their software (deno, rust) is packaged in nixpkgs, and instead mention the install script. Actually Deno mentions nixpkgs, and Rust mentions apt on their less immediately visible docs, but the first recommendation is to use the install script.
The core problem mentioned here is one of packager control vs developer control. With an install script that downloads a binary (usually vendored) the developer has control over things like: the version of the software, how it is installed, and what libraries it uses. They like this for a variety of reasons, but it often comes to the detriment of user security for the reasons I have mentioned above. Please, please read the blog post about static linking or look into my cargo audit. Developers are not security experts and should not be allowed to install software, even though they want to and continue to do this.
One the other hand, with package maintainers, they value the security of users more than things like getting a new version out. With package maintainers however, they take control over how packages are installed, often using older versions to dodge new security vulnerabilities, at the cost of keeping the same set of non-security related bugs, and sometimes the developers whine about this, like when the Bottles devs tried to get unofficial versions of bottles taken down. Bottles even intentionally broke non-flatpak builds.
But I don’t care about developer control. I don’t care about the newest version. I don’t care about the latest features. I don’t care about the non-security bugs not getting ironed out until the next stable release. Developers care about these things.
But I care only about the security of the users. And that means stable release. That means package managers. That means developers not installing software.
It’s just a way to make bash installers more secure.
bash installers from the developers, and vendored/pinned dependencies in general will never be secure for the reasons I mentioned above. Developers are bad at security. Developers should not be installing software on people’s machines.
I said that the tool would have to be installed by default on the main distros. I would be a single binary and a man page. I don’t think it would be very difficult to get it included.
It is very difficult. The core problem here is the philosophy of the distros will cause them to avoid this tool for various reasons. Minimalist distros, like Arch, will avoid this by default because they are minimal. On the other hand, Debian really dislikes users not using packages to install things, for a variety of reasons that could be their own post, but the short version is that they also won’t package this tool. A gentoo developer explains some of this, but also why staticly compiled (single binary) setups are disliked by distro packages as well.
It’s a very long post, but to paraphrase a common opinion from it: Developers are often bad at actually installing software and cannot really be trusted to manage their own installer, and the dependencies of the software they create. For example, here is a pastebin of me running cargo-audit on Deno. Just in that pastebin, there are two CVE’s, one is 5.9, and also an unmaintained package. Except, one of the CVE’s has a patch available. But, in the Cargo.lock:
[[package]]
name = "hickory-proto"
version = "0.25.0-alpha.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d063c0692ee669aa6d261988aa19ca5510f1cc40e4f211024f50c888499a35d7"
They have “vendored” and “pinned” the package, meaning that it is essentially stuck on an insecure version. Although I’m sure that this version will be updated shortly, what sometimes happens is that a non-backwards compatible update that includes a security fix is released, and lazy developers, instead of updating their software, will pin the insecure version.
In a distro’s package manager, the distro would step up to patch vulnerabilities like that one, or do security maintenance for unsupported packages. Although Debian’s extremely slow movement is frustrating, they are a particularly excellent example of this because they maintain packages in such a way that all their packages are backwards compatible for the duration of their lifecycle in the stable release, meaning that a developer making a package for Debian would have no need to pin the version, but they would still get security updates for the libraries they are using for 6 years.
Deno is an extremely popular package, and thankfully it has very few issues, but I have seen much worse than this, and it’s because of issues like these that I am generally opposed to developers being package maintainers, and I think that should be left up to distro maintainers or package maintainers.
There’s 0 security. Even tarballs are usually provided with MD5 checksum that you can verify client side. With bash there’s nothing
MD5 hashes are not enough. Modern packaging systems, like Debian’s or Arch’s have developers sign the packages to ensure that it was the real developer (or at least someone on the real developers computer…) who uploaded the package. Even with MD5 hashes, there is no such verification.
The other step needed is reproducible builds: If multiple people build a package, they will have the same output. I can verify the XZ tarball and see that the MD5 hash matches, but it’s meaningless when that tarball has a backdoor in it, because they added something when they compiled it on their own machine (real story btw, also the xz backdoor didn’t make it into Debian stable because of Debian’s slow release policy and the fact that they essentially maintain and build forks of their own packages).
If the rust binary is not being built reproducibly, then it’s meaningless to verify the MD5 hash.
But all the website already use bash scripts.
I mentioned an alternative to the what these websites do, using a package manager to install these instead of their bash scripts.
It’s not a package manager based on bash.
Both of the bash scripts you mentioned as an example are being used to install software. If you have examples of bash scripts that do things other than install software, then it’s worth discussing how to handle those.
However, the reason why bash is so popular for usecases like configuration scripts or an Arch install script though, is because no other software besides wget/curl and bash is required to get it. Having to get an extra tool on the Arch install iso just to run an install script in bash, or to run a script that installs tools on a fresh, clean install, somewhat defeats the point of the script being written in bash imo.
It’s secure way to distribute bash scripts that are already being distributed in a insecure way.
Bash is inherently insecure. I consider security not just issues with malice, but also footguns like the steam issues mentioned above. Centralizing all the bash scripts to a “repo” doesn’t fix the issues with arbitrary bash scripts.
And if you are concerned about malice, then the bash scripts almost always download a binary that does further arbitrary code execution and cannot be audited. What’s the difference between a bash script from the developers website and a binary from the developers website?
There is uksmd for ram dedupe.