To be honest, not a great argument, considering that the hidden magic that Google and a handful of big players do, specifically in relation to spam, is what made emails substantially an oligopoly. Today if you want to run an email server, you need to jump 20 hoops to hope your email will ever reach the mailbox of someone on Gmail. Emails were supposed to be a distributed protocol too...
Ansible is definitely one way to do this. If your machines are VMs, then also building VM images with packer can be the way.
For tmux, vim, etc. You can still use ansible or some specific tool for dotfiles, like chezmoi (there are a bunch). You can even use ansible to run chezmoi!
Oh no, I get it, I was quite scared the first time I messed with it, and I cursed LG plenty for not letting me install safely what I want on my own TV. I found this technique to be quite safe though. You basically uninstall the official YouTube app, then do the loading and you can always remove the app and reinstall the official one.
I hope I didn't sound condescending, I just realized that I had been a bit too quick labeling something easy, while I understand that for some other person reading, using a CLI tool is in itself a new thing. Good luck :)
The procedure to install is very easy, you can also always uninstall it and reinstall the official one, I don't think it's irreversible in any way. Note that I am talking about side loading using developer mode. Rooting the TV via an exploit can brick your TV instead.
I think the answer is fairly simpler, from my point of view: because NATO is not a military alliance among peers. It is the military arm of the American empire. This allows US to essentially manage the foreign policies of most of NATO members, but it also comes with the cost of being the one paying the bills. Empires are expensive.
I will skip commenting the rest because, well, you are entitled to your own opinion and you can loathe who you want. I would perhaps simply suggest to look at your own country with an outside perspective and realize that if everyone used your same logic, the world will be a more hateful place than already is.
I use https://github.com/webosbrew/youtube-webos on my LG TV, to watch without ads. I have to sideload it via the CLI tools, but it works. Sometimes I have to reinstall it (I suppose some TV update screws up), but for my partner watching without ads is worth the random sporadic breakage.
Some additional benefits also are the management of secrets. In compose you will shove them inside a .ENV file if not directly inside the compose file, while in Kubernetes you can use the secrets resource or even plug in Vault relatively easily.
Stateful storage is also better handled. Named volumes are nasty to keep track of, backup and it's not possible to spread them across multiple devices (as in disks) while bind mounts are insecure in general. Kubernetes provides a storage abstraction which is easier to manage.
Obviously the big advantage comes when you want to run stuff on multiple devices to spread the load (or because the one box is saturated), since with compose you would need completely custom and independent setups.
Finally, I would say that running compose makes it much harder to have a monitoring stack supporting your services, since you will need to do all the plumbing for metrics endpoints yourself. And - very last - you can have admission controllers in Kubernetes that prevent certain configuration (e.g. Kyverno with a bunch of default policies), while with compose you need to manually vet every compose file and image (for example, to ensure it doesn't run as root).
That said, compose is perfect to get started and to run stuff on one machine.
If you containerize, the application (malware) will run under the user configured in the image, unless you override it, and in a separate mount namespace, unless you change that, which makes the "alias sudo" trick extremely unlikely.
Even running under a separate user anyway prevents almost fully the attack you mention, unless the separate user has root privileges or the DAC_OVERRIDE capability is assigned to the binary (assigning it requires CAP_SYS_ADMIN).
In short, the attack you mention is a common persistence and privilege escalation vector, which is relatively easy to detect (watch for changes to shell profiles), although preventing it requires some care.
I just want to point out that in single-user machines (e.g. personal computers) escalating to root is anyway fairly unnecessary, given that all the juicy stuff (ssh keys, data, etc.) is anyway probably running under/owned by that user.
Vulnerabilities can and are usually found without code inspection. Fuzzing, reverse engineering, etc. At the same time, it is easier to find vulnerabilities having the code to check, but it is easier also for those who want to have them patched. That's why we have tons of CVEs in Windows, iOS etc., and they don't all come from the vendor... Depending on the ratio of eyeballs looking at something to fix and the ones looking at something to exploit, open source can be more secure compared to closed source.
Oh yeah, this makes absolutely sense. I do use simplelogin only for things I don't really care about, but it is definitely a good point what you are saying.
I am not sure I understood your comment. I am using protonmail (ultimate) and they do have free simplelogin integration (I think proton bought SL). Definitely catchall is my way to go for reputable sites, but SL is great for trash "register once" sites so that I don't even disclose my domain!
OK, but how do you solve the problem? Trusting an image is not so different than downloading a random deb and installing it, which maybe configures a systemd unit as well. If not containers you still have to run the application somehow.
Ultimately my point is that containers allow you to do things securely, exactly like other tools. You don't even have to trust the image, you can build your own. In fact, almost every tool I add to my lab, I end up opening a PR for a hardened image and a tighter helm chart.
In any case, I would not expose such application outside of a VPN, which is a blanket security practice that most selhosters should do for most of their services...
They are not as secure, because there are less controls for ENV variables. Anybody in the same PID namespaces can cat /proc/PID/environ and read them. For files (say, config file) you can use mount namespaces and the regular file permissions to restrict access.
Of course you can mess up a secret implementation, but a chmod'd 600 file from another user requires some sort of arbitrary read vulnerability or privilege escalation (assuming another application on the same host is compromised, for example). If you get low-privileged access to the host, chances are you can dump the ENV for all processes.
Security-wise, ENV variables are worse compared to just a mounted config file, for example.
The problem is in fact in the applications. If these support loading secrets from a file, then the problem does not exist. Even with the weak secrets implementation in kubernetes, it is still far better than ENV variables.
The disappointing thing is that in many "selfhost" apps, often the credentials to specify are either db credentials or some sort of initial password, which could totally be read from file or be generated randomly at first run.
I agree that the issue is information disclosure, but the problem is that ENV variables are stored in memory, are accessible to many other processes on the same system, etc. They are just not a good way to store sensitive information.
In general, a mounted file would be better, because it is easier to restrict access to filesystem objects both via permissions and namespacing. Also it is more future proof, as the actual ideal solution is to use secret managers like Vault (which are overkill for many hobbyist), which can render secrets to files (or to ENV, but same security issue applies here).
To be honest, not a great argument, considering that the hidden magic that Google and a handful of big players do, specifically in relation to spam, is what made emails substantially an oligopoly. Today if you want to run an email server, you need to jump 20 hoops to hope your email will ever reach the mailbox of someone on Gmail. Emails were supposed to be a distributed protocol too...