[Feature request] Define valid mount options for valid volumes #407

New Issue

mpeter · 2023-11-17T21:37:48Z

mpeter commented

2023-11-17 21:37:48 +00:00

In the act runner's configuration the container.valid_volumes can be used to set a list of volumes that can be mounted inside containers.
Volumes listed here can always be mounted with any option, including in writable mode, by jobs running on the runner.

Sometimes you need to allow volumes because you want its files to be available in all of the containers, regardless of the job's configuration, by specifying them with a --volume option in the container.options setting, like this: options: "--volume /etc/ssl/certs:/etc/ssl/certs:ro".
One such case is when your Gitea server uses self-signed, locally trusted certificates. The runner has a configuration for that, runner.insecure, but that is insufficient:

it turns off TLS certificate verification for the runner, decreasing security beyond what is necessary
processes in the job containers, like git, will still complain about the unknown certificate, and so actions like checkout wouldn't be able to work

Installing the certificate to the docker host system, and mounting in the certificate store directory will allow it to work, but currently it also poses a security issue: while I have made sure that my certificate dir bind mount is read-only, a workflow's job configuration can just request mounting the same directory of the host to a new path with no read-only restriction, as it has been allowed, and delete or replace the certificates on the host system.

This is especially problematic as jobs are running as the root user account in the job containers, so they actually have the power to meddle with the certificate store of the docker host:

I think a solution to this problem could be to make container.valid_volumes support docker mount option restrictions in some form.
The option would be compatible with its current form, so valid_volumes: [ "/etc/ssl/certs" ] would allow writable mounts, but valid_volumes: [ "/etc/ssl/certs:ro" ] (following the docker --volume syntax) or a different way would allow limiting how the volume should be mounted.
If jobs have no way to request volumes to be mounted with volume options for special volume drivers, its probably fine if only the --volume syntax is supported.

Besides supporting environments with self-signed TLS certificates, I'm sure this would be useful for other situations too.

In the act runner's configuration the `container.valid_volumes` can be used to set a list of volumes that can be mounted inside containers. Volumes listed here can always be mounted with any option, including in writable mode, by jobs running on the runner. Sometimes you need to allow volumes because you want its files to be available in all of the containers, regardless of the job's configuration, by specifying them with a `--volume` option in the `container.options` setting, like this: `options: "--volume /etc/ssl/certs:/etc/ssl/certs:ro"`. One such case is when your Gitea server uses self-signed, locally trusted certificates. The runner has a configuration for that, `runner.insecure`, but that is insufficient: - it turns off TLS certificate verification for the runner, decreasing security beyond what is necessary - processes in the job containers, like `git`, will still complain about the unknown certificate, and so actions like checkout wouldn't be able to work Installing the certificate to the docker host system, and mounting in the certificate store directory will allow it to work, but currently it also poses a security issue: while I have made sure that my certificate dir bind mount is read-only, a workflow's job configuration can just request mounting the same directory of the host to a new path with no read-only restriction, as it has been allowed, and delete or replace the certificates on the host system. This is especially problematic as jobs are running as the root user account in the job containers, so they actually have the power to meddle with the certificate store of the docker host: ![image](/attachments/4e3a2ddb-3c9e-4ca1-9851-eedd96ae3452) I think a solution to this problem could be to make `container.valid_volumes` support docker mount option restrictions in some form. The option would be compatible with its current form, so `valid_volumes: [ "/etc/ssl/certs" ]` would allow writable mounts, but `valid_volumes: [ "/etc/ssl/certs:ro" ]` (following the docker `--volume` syntax) or a different way would allow limiting how the volume should be mounted. If jobs have no way to request volumes to be mounted with volume options for special volume drivers, its probably fine if only the --volume syntax is supported. Besides supporting environments with self-signed TLS certificates, I'm sure this would be useful for other situations too.

image.png

29 KiB

mpeter commented

2023-11-17 21:42:09 +00:00

According to the docker docs, the options in the --volume syntax can be a comma separated list of values.
What it accepts varies by the volume driver, the default "local" driver accepts the options of the linux mount command (e.g. ro, noatime, noexec, ...)

According to the [docker docs](https://docs.docker.com/storage/volumes/#choose-the--v-or---mount-flag), the options in the `--volume` syntax can be a comma separated list of values. What it accepts varies by the volume driver, the default "local" driver accepts the options of the linux `mount` command (e.g. `ro`, `noatime`, `noexec`, ...)

mpeter commented

2023-11-17 21:45:04 +00:00

I would appreciate if this issue could get a security label assigned. It looks theres no such label yet, but I think it would be useful, as one of the software's jobs is to attempt to run arbitrary code securely, where it can.

schallbert referenced this issue

2023-12-29 13:00:41 +00:00

Volumes not being mounted in Actions containers #329

mpeter commented

2024-07-11 22:24:11 +00:00

This would help in solving #568

mpeter referenced this issue

2024-07-19 15:36:09 +00:00

Support for selfsinged ca/certs #568

Sign in to join this conversation.