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 that’s good to see! Sorry if I didn’t expand much before, I was writing from my phone.

Good luck :)

I did exactly this in https://github.com/Sudneo/Home-ddns, and it works pretty OK for me for more than a year

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).

Absolutely not. Many applications used ENV variables for sensitive stuff even before. Let’s remember that the vulnerability here is being able to execute phpinfo remotely.

Containerization can do good for security, in general.

The only thing that makes this case worse in docker is that more info is in ENV variables. The vulnerability has nothing to do with containers though, and using ENV variables to provide sensitive data is in general a bad decision, since they can be leaked to any process with /proc access.

Unfortunately, ENV is still a common way which people use to pass data to applications inside containers, but it is not in any way a requirement imposed by the tech.

There are various types of “spaghetti”, from the thin ones to quite thick, then vermicelli, spaghetti quadrati, spaghetti alla chitarra etc…Definitely you can’t replace spaghetti with fettuccine in all instances, IMHO.

That said, I am team vermicelli (which are thicker). But spaghetti from a good pasta brand (for supermarket stuff, say Rummo, Liguori) are just another thing compared to the Barilla stuff.

Add the DAC_READ_SEARCH capability to the restic binary (using setcap).This is what allows to read all files. Obviously this means being able to read all, all, files including shadow etc.

Sorry for the late answer. My point is that the problem is upstream to the issue of quoting/non quoting. A person who gets convinced by a nazi/antisemitic slogan is already a problem on itself. The quote is one of the N ways that person can be exposed to ideas that underneath they already support, and I don’t think this is a good reason to change the way that we talk about some issues. In other words, even if someone “gets recruited” by the quote, this is merely surfacing the problem, it’s not creating it.

Vatican City /s

I think that there are constraints for certain countries, but the majority probably could. And when they can’t, it should be solved by cooperation and trade, IMHO.

I mean, it’s not a spell, it’s a sentence. If reading it will make it spread, as in more people will agree and support it, the problem is already there.

+1 for kagi. I think they have a smaller subscription too. Also not too long ago they changed the 10$ subscription from 700 searches/month to unlimited, which gives hope that they might improve the pricing over time.

As a side note, it is surprising how many searches one does during the month! I thought I did thousands per month, turns out I am always between 200 and 400!

OK :)

So chroot has not been used to isolate processes for decades to a confined view of the filesystem (especially in combo with a restricted shell), and for example the networking namespace is not used to limit the impact on a compromise on the firewall, the user namespace is not used to allow privileged processes to run de-facto unprivileged.

Whatever you say

EDIT: Actually, if you are really convinced of what you are saying we can do the following experiment:

• We spin up a VPS and run a web application with a RCE with a Systemd unit and run the same web app in a scratch container running under an unprivileged user

Then we can compare the kind of impact that using containers to wrap applications has on the security of the system. My guess, even with a full RCE you will not be able to escape the container.

Half-jokes aside, my stance is that isolation (namespacing and cgroups) allows to greatly reduce the attack surface and contain the blast radius of a compromise, which are security benefits. You can easily have a container with no shell, no binaries at all, no writable paths, read-only filesystem etc. You can do at least some of those things even in a regular Linux box of course, but it is much more uncommon, much harder, much less convenient (for example, no writeable /tmp is going to break a lot of stuff), much more error prone, etc.

Your stance i.e.:

running things inside of a container does not provide any security benefits as opposed to outside of the container

is way too absolute, imo.

Not really true, containers are based on namespaces which have always been also a security feature. Chroot has been a common “system” technique, afterall.

Containers help security if built properly, and it’s easier to build a container securely (and run them), compared to proper SystemD unit security.

tl;dr, yes, it does.

Containers are nothing like VMs, and containers in Linux are basically a combination of a feature called Cgroups, which allows to restrict the resources (like memory, etc.) available to a process or group of processes, and namespaces. Namespaces are a construct in which certain namespaced resources are separated from each other, and processes can only see those belonging to their namespace. A simple example is a mount namespace. When you launch a container, you see a / directory which is not the root directory of your system.

Now, the problem is, that not all the resources are namespaced, so there is still quite a lot that processes within containers can do interacting with the main system resources, especially if they are root.

A root process within a container generally can do lots of things that the actual root process can do outside of it. For example, mounting parts of the filesystem (if you run with --privileged), loading kernel modules, etc. Podman can run rootless, in the sense that it uses also User namespaces, meaning a user 0 (root) inside a container is actually mapped to something else outside, but also docker nowadays can do the same.

So yeah, in general, running the applications with the less amount of privileges is a good idea and you should do it whenever you can. Even if you do need some privileges, you should add only the Capabilities needed, not just go straight to root.