3 ms·

if you're worried about arbitrary code exec from an ffmpeg vuln, docker is not a sufficient security boundary.

• baggy_trough 1y ago
  What is?
  • ethersteeds 1y ago
    Full virtualization. Docker implies a shared kernel attack surface, that's what you want to avoid.
    • afiori 1y ago
      Kernel level exploits are more dangerous but also way less common, for a lot of places docker is sorta okay as a security boundary
      • ta1243 1y ago
        It's layers. Docker is better than nothing, but a VM is better still, and even better is docker on a dedicated VM on dedicated hardware on a dedicated network segment.
        • mschuster91 1y ago
          That's sacrificing an awful lot of latency cost for each transcode job though.
          • ethersteeds 1y ago
            Each job sends a provisioning ticket to a thermal printer. 1 business day turnaround, unless we need to order more servers
          • xxpor 1y ago
            Firecracker says it can start a VM in 125 ms, for most transcode jobs that seems like it'd be a trivial cost.
        • afiori 1y ago
          To make a bit of a strawman of what you are saying even better still would be an unplugged power cable as a turned off machine is (mostly) unhackable. To be more serious seurity is often in conflict with simplicity, efficiency, usability, and many other good things. A baseline level of security (and avoidance of insecurities) should be expected everywhere, docker allows many places to easily reach it and is often a good enough tradeoff for many realities.
        • endre 1y ago
          that escalated quickly. but I agree.
  • dividuum 1y ago
    I've build a custom thumbnail/metadata extraction toolkit based on libavcodec/libavformat that runs the decoding in seccomp's strict mode and communicates the results through a linear RGB stdout stream. Works pretty well and has low overhead and complexity. Full transcoding would be a bit more complex, but assuming decoding is done in software, I think that should also be possible.