[Feature Request/Security] Support for read_only with Docker image

[OdinVex]

If it's possible, could the Docker image be adjusted to support read_only: true so the Docker image filesystem is set to readonly? In short, the entire image (except perhaps /tmp and wherever the permanent files/such/logs exist) is read_only when started via Docker to prevent writing to anything except what is mounted as rw (volumes/etc).

Edit: If /etc/dns is the only thing wrote to it's easy to support. Edit: /etc/dns and /tmp appear so far to need mount (or tmpfs for /tmp).

[ShreyasZare]

Thanks for the request. Can you provide more context or explain scenario where it would be useful?

[OdinVex]

Thanks for the request. Can you provide more context or explain scenario where it would be useful?

I already did in the first post. Setting the container to read_only prevents writes to the container filesystem (aside from whatever is mounted).

For anyone else your compose would be setup such as this:

   ...
    read_only: true  # To comply with any security requirements
   ...
    volumes:
      - YourTechnitiumDataDirectory:/etc/dns:rw  # Important
      - /etc/localtime:/etc/localtime:ro  # Optional
      - /etc/timezone:/etc/timezone:ro  # Optional
      - type: tmpfs
        target: /tmp
        tmpfs:
          size: 2000000000  #2GB

I chose a 2GB tmpfs for the /tmp because I've plenty to spare from RAM but you could also do a mount, one or the other would be needed.

[ShreyasZare]

Thanks for the request. Can you provide more context or explain scenario where it would be useful?

I already did in the first post. Setting the container to read_only prevents writes to the container filesystem (aside from whatever is mounted).

The container itself is used to prevent writes to host file system.

For anyone else your compose would be setup such as this:

   ...
    read_only: true  # To comply with any security requirements
   ...
    volumes:
      - YourTechnitiumDataDirectory:/etc/dns:rw  # Important
      - /etc/localtime:/etc/localtime:ro  # Optional
      - /etc/timezone:/etc/timezone:ro  # Optional
      - type: tmpfs
        target: /tmp
        tmpfs:
          size: 2000000000  #2GB

I chose a 2GB tmpfs for the /tmp because I've plenty to spare from RAM but you could also do a mount, one or the other would be needed.

There may be use-case for having a read-only container for some scenarios but here there are uses who do not expect this and wish to install additional tools. So, its not feasible to make this change for the official docker image.

I would suggest that you build a custom docker image so that you can have read-only support and any further customization.

[OdinVex]

It's not something you can add to the container image, you specify read_only via CLI or compose. What I'm hoping to accomplish is standardization of plugins/Technitium so that Technitium only writes to /etc/dns/... and/or /tmp/... so the behavior can be relied upon without breaking Technitium. It's merely documentation you could add regarding deployment for securing the image. Perhaps a note about making sure plugins that write to a directory do so only in /etc/dns/... or for temporary writings /tmp/....

(Edit: So as long as Technitium and plugins write to to /etc/dns/... and/or /tmp/... we can better secure deployments using read_only which sets the image filesystem read_only preventing any writes where there shouldn't be any.)

[ShreyasZare]

It's not something you can add to the container image, you specify read_only via CLI or compose. What I'm hoping to accomplish is standardization of plugins/Technitium so that Technitium only writes to /etc/dns/... and/or /tmp/... so the behavior can be relied upon without breaking Technitium. It's merely documentation you could add regarding deployment for securing the image. Perhaps a note about making sure plugins that write to a directory do so only in /etc/dns/... or for temporary writings /tmp/....

(Edit: So as long as Technitium and plugins write to to /etc/dns/... and/or /tmp/... we can better secure deployments using read_only which sets the image filesystem read_only preventing any writes where there shouldn't be any.)

Oh ok. I am not a docker expert so misunderstood the post, apologies for the same. Technitium DNS server does write only to the /etc/dns/ config folder apart from temp files which are created as per the system's temp path. The plugins/apps have their own folder in /etc/dns/apps where they can write files. So, there should not be an issue if you try to create read-only container.

[OdinVex]

Oh ok. I am not a docker expert so misunderstood the post, apologies for the same. Technitium DNS server does write only to the /etc/dns/ config folder apart from temp files which are created as per the system's temp path. The plugins/apps have their own folder in /etc/dns/apps where they can write files. So, there should not be an issue if you try to create read-only container.

That's alright and great news for those of us that have been required to secure all Docker containers, great to know those should be the only paths that need rw mounts. This could be added to the documentation for Docker deployments of Technitium, to reduce attack depths. :)

[xlionjuan]

Just a quick hint, you can always analyse any container with docker diff {container name} to see which files are modified or added, for lot's of software, it may create a pid files at /run or /var/run etc.... After you know that, you can mount those folders to tnpfs and check if running container as read_only possible.

[OdinVex]

Just a quick hint, you can always analyse any container with docker diff {container name} to see which files are modified or added, for lot's of software, it may create a pid files at /run or /var/run etc.... After you know that, you can mount those folders to tnpfs and check if running container as read_only possible.

For running containers, correct?

[xlionjuan]

Yes I'm saying containers

[OdinVex]

Yes I'm saying containers

I know you meant containers, I was asking if they had to be running or suspended.

[xlionjuan]

Of course you need to run diff when container running, because program will cleanup its pid or some cache files when it stopped, diff will not affect any running containers, it just some forms of status checking.

[OdinVex]

Of course you need to run diff when container running, because program will cleanup its pid or some cache files when it stopped, diff will not affect any running containers, it just some forms of status checking.

Never said anything about stopped, suspend is not stopped, it's pausing execution to prevent any possible cleanup or transient filesystem operations.

[xlionjuan]

Of course you need to run diff when container running, because program will cleanup its pid or some cache files when it stopped, diff will not affect any running containers, it just some forms of status checking.

Never said anything about stopped, suspend is not stopped, it's pausing execution to prevent any possible cleanup or transient filesystem operations.

Just run diff at running, no suspend needed.

[xlionjuan]

Note: You need to make /tmp able to run executable in order to run SQLite App

Compose:

    tmpfs:
      - /tmp:mode=770,exec