Comment on Docker security

gerowen@piefed.social ⁨2⁩ ⁨weeks⁩ ago

• atzanteol@sh.itjust.works ⁨2⁩ ⁨weeks⁩ ago

  Containers run “on bare metal” just as much as non-containerized applications.

  source
• prettybunnys@piefed.social ⁨2⁩ ⁨weeks⁩ ago

  When you say you’re using systems to lock down/containerize things as necessary can you explain what you mean?

  source

  • moonpiedumplings@programming.dev ⁨2⁩ ⁨weeks⁩ ago

    I don’t know what the commenter you replied to is talking about, but systemd has it’s own firewalling and sandboxing capabilities. They probably mean that they don’t use docker for deployment of services at all.

    Here is a blogpost about systemd’s firewall capabilities: ctrl.blog/…/systemd-application-firewall.html

    Here is a blogpost about systemd’s sandboxing: www.redhat.com/en/blog/mastering-systemd

    source
  • gerowen@piefed.social ⁨2⁩ ⁨weeks⁩ ago

    Systemd has all sorts of options. If a service has certain sandbox settings applied such as private /tmp, private /proc, restricting access to certain folders or devices, restricting available system calls or whatever, then systemd creates a chroot in /proc/PID for that process with all your settings applied and the process runs inside that chroot.

    I’ve found it a little easier than managing a full blown container or VM, at least for the things I host for myself.

    If a piece of software provides its own service file that isn’t as restricted as you’d like, you can use systemctl edit to add additional options of your choosing to a “drop-in” file that gets loaded and applied at runtime so you don’t have to worry about a package update overwriting any changes you make.

    And you can even get ideas for settings to apply to a service to increase security with:

    systemd-analyze security SERVICENAME

    source