Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Docker is a security risk. Is it possible to install securely?
I imagine you can use Podman instead
I think that has the same problems, no? Or does podman do signature verification on all the layers it downloads from the container registry?
Docker is a security risk? … excuse me, what? Can’t you just, idunno, secure the environment that docker runs in? Use rootless images? Use immutable images?
And, are you asking for something that runs on bare metal? Couldn’t you just install the ISO that the dockerfile uses, then convert the dockerfile logic to an sh script?
Doker pull is insecure
It's the download that's not verified
Download the image manually with something like curl???
Hahahahahaha good luck.
You can verify the checksum to ensure the contents pulled are exactly the same as what was published. You can also use a private container registry.
How exactly would docker pull be any more insecure than something like pip install? Or, really anything… Let’s go with your preferred alternative, how are you going to get it on your machine in a more secure way than docker provides?
Docker uses TLS with registries, layers and manifests have cryptographic digests, checksums, and you can verify the publisher yourself. Push it into your own registry if you want, or just don’t use
latest.Yeah, that's the insecurity I'm talking about.
If you want to know how to implement this properly, look at apt. Its a known issue in docker; they just haven't prioritized the fix yet (DCT)
What are you talking about, “yeah that’s the insecurity I’m talking about.”
I didn’t mention an insecurity and neither have you. Would you mind being a little more clear than “Docker pull is insecure?”
Frankly, I was expressing confidence in dockers security. It goes without saying though, any user can do insecure things like download from untrusted sources. That’s not dockers problem though, it’s the users.
Edit: I see now that you added “it’s the download that’s not verified.” Integrity is verified, so I assume you mean authorship (via signing)? I guess you’re saying that, if admin credentials are stolen from a container publisher and the thief force pushes malicious code into the registry under a pre-existing tag—then you would be exposed to that?
Even in that case, though, a digest cannot be overwritten. Tags can. So you’d just pin the digest to avoid this one attack vector?
Checksums are not for security. You need signatures. I'm not making claims that aren't clearly documented.
You’re talking about authorship. Sure. But if you verify the container yourself as secure and pin the digest, what’s the issue?
What you just described cannot be done. You can't verify it, because its not signed.
You’re making big claims on security here, like “cannot be done,” and each time you do I feel like we’re talking past each other a bit. I never claimed you can verify that the person who pushed the container had access to a private key file. I claimed you can verify the security of a container, specifically by auditing it and reviewing the publisher’s online presence. Best practices. Don’t upgrade right away, and pin digests to those which can be trusted.
When you pin a digest, you’re not going to get a container some malicious agent force pushed after the fact. You pinned the download to an immutable digest, so hot-swapping the container is out the window. What, as I understand, you’re concerned with is the scenario that a malicious actor (1) compromised the registry login beforehand, (2) you pinned the digest after hand, and (3) the attack is unnoticed by you and everyone else.
I’m trying to figure out under what conditions this would actually occur, and thus justifies the claim that
docker pullis insecure. In a work setting, I only see this being an issue if the process to test/upgrade existing ones is already an insecure process. Can you help me understand why I should believe that, even with best practices in place, Dockers own insecurities are unacceptable? Docker is used everywhere and I’m reluctant to believe everyone just doesn’t care about an unmanageable attack vector.In its default state i think thats fair. Example docker bypasses most firewalls as it runs before iptables rules process. So if you don't either use 127.0.0.1:port:port (many compose files offered by projects do not do this) or add specialized iptables rules to fix that up you can end up directly exposing services with meaning to or even realizing.
And yeah privilege escalation etc. There are solutions like what you mentioned but it can be a lot of work to set all that up so most people won't