sudneo

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.