As always you store data you want to keep in the volumes section.
With read-only you prevent new binaries from being added in the image space. You can add ânoexecâ to your volumes/tmpfs preventing binaries to the areas that are writable. Then ideally you are using an image with minimal surface area (e.g., only sh and the exact binaries needed to make it go) and itâs very secure! Itâs still plenty secure without a minimal image.
Lem453@lemmy.ca â¨3⊠â¨days⊠ago
Couldnât the attacker just drop a dangerous binary into the data volume then?
glizzyguzzler@piefed.blahaj.zone â¨3⊠â¨days⊠ago
Not if you annotate your data volume with said ânoexecâ which prevents execution from anything in the data volume. It looks like this, you can slam it on any volume you like - no volumes should have executables in them anyways.
Also Iâm pretty sure ânoexecâ is the default, so thatâs by default protected. But I canât confirm that from a quick search so not 100% on that.
â/mnt/data:/container/place/it/wants:rw,noexec,nosuid,nodev,Zâ
ârwâ means read/write. You can change it to âroâ for read-only if the volume shouldnât write to it (maybe a config file).
Z is for selinux that means âonly one program can read/write tho thisâ. You can change it to âzâ lowercase in case more than one needs to read/write. Only case Iâve found for little z is crowdsec needing to watch Caddyâs log for blocking.
Lem453@lemmy.ca â¨3⊠â¨days⊠ago
This is great. Thanks!