Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

maskedPaths and readonlyPaths: skip non-existent paths #982

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

alban
Copy link
Contributor

@alban alban commented Aug 2, 2018

runc ignores non-existent paths in maskedPaths and readonlyPaths. That's useful for blocking /proc/latency_stats (default in buildah) because this path is not existing on all kernels.

In this case, no error should be generated. Other errors should be generated. For example, using readonlyPaths on a unbindable path fails and this error must be generated, otherwise the path would silently stay read-write.

Signed-off-by: Alban Crequy alban@kinvolk.io

@alban alban changed the title maskedPaths and readonlyPaths: ignore unexistent paths maskedPaths and readonlyPaths: ignore non-existent paths Aug 2, 2018
@cyphar
Copy link
Member

cyphar commented Aug 4, 2018

While I understand why readonlyPaths might be okay to ignore (though I'd be worried about the security implications -- really I think an empty file or empty directory should be made and then re-binded as ro), maskedPaths MUST NOT be ignored. They should always be made masked and inaccessible. If currently runc doesn't do this, it should be fixed rather than the incorrect behaviour codified in the specification.

@crosbymichael
Copy link
Member

@cyphar runc is not ignoring any of them. I tries to setup the ro or mask, but if the destination does not exist, then there is nothing for it mask or ro so it returns nil in this case. I think the runc functionality is correct but the spec change with the wording ignore could be a little dangerous.

@cyphar
Copy link
Member

cyphar commented Aug 6, 2018

I'm not sure that that this is correct though -- it depends what a user expects and what people want to use masking for. If we're told to mask a non-existent path then we arguably should still mask it (to be fair, we won't be able to figure out if we should put a file or a directory over the path). The concern would be that the path isn't immediately available, but we want to make sure that the container process can never access that path. Of course, on the other hand, runc does not traditionally modify rootfs and so doing so could cause confusion...

@crosbymichael
Copy link
Member

I'm not sure that would work, we mask an non-existent path and then someone mounts over the top later, it's not masked.

@alban
Copy link
Contributor Author

alban commented Aug 10, 2018

We cannot always create an empty file or directory when the destination is non-existent: in the example of /proc/latency_stats, we cannot touch or mkdir in procfs.

I think the current runc behaviour is fine.

runc can only masking paths it knows about at the time the container is set up. Subsequent mounts cannot be protected with maskedPaths. Users should just not give CAP_SYS_ADMIN for subsequent mounts.

Unexistent paths MUST be ignored without generating an error.

Any other suggestion for the word ignore?

runc ignores unexistent paths in maskedPaths and readonlyPaths. That's
useful for blocking /proc/latency_stats (default in buildah) because
this path is not existing on all kernels.

In this case, no error should be generated. Other errors should be
generated. For example, using readonlyPaths on a unbindable path fails
and this error must be generated, otherwise the path would silently stay
read-write.

Signed-off-by: Alban Crequy <alban@kinvolk.io>
@alban alban force-pushed the alban/missing-paths branch from 2d8d6d9 to c5e0999 Compare August 15, 2018 13:34
@alban alban changed the title maskedPaths and readonlyPaths: ignore non-existent paths maskedPaths and readonlyPaths: skip non-existent paths Aug 15, 2018
@crosbymichael
Copy link
Member

should this be a MUST or SHOULD?

@cyphar
Copy link
Member

cyphar commented Nov 14, 2018

If anything it should be SHOULD, but I'm still not a fan of this...

Copy link
Member

@vbatts vbatts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not terribly opposed to this, but do not think it is a MUST

@@ -635,6 +635,7 @@ The following parameters can be specified to set up seccomp:

**`maskedPaths`** (array of strings, OPTIONAL) will mask over the provided paths inside the container so that they cannot be read.
The values MUST be absolute paths in the [container namespace](glossary.md#container_namespace).
Unexistent paths MUST be skipped without generating an error.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Unexistent" is not a word. Either "inexistent" or "nonexistent".
And this is best a SHOULD, not a MUST.

@@ -648,6 +649,7 @@ The following parameters can be specified to set up seccomp:

**`readonlyPaths`** (array of strings, OPTIONAL) will set the provided paths as readonly inside the container.
The values MUST be absolute paths in the [container namespace](glossary.md#container-namespace).
Unexistent paths MUST be skipped without generating an error.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same

@h-vetinari h-vetinari mentioned this pull request Feb 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants