> Christophe, looks like you are running a rootless
> container there with podman(I'll let you confirm),
> which explains the permissions issue, whereas
> containers launched with k8s are launched as root.
I'm running podman as root, if that's what you are asking.
However, even in that case, the container root user is
not host uid 0, but uses namespaces to map that to some
other user. This is the reason of the failure above.
Apparently, the behavior reported for k8s does not happen with OpenShift either. OpenShift, like podman, blocks this particular form of attack. I suspect it would be possible to achieve a similar result with a privileged container, however.
> I mentioned this as a way to get rid of regular
> expressions in the configuration.
In comment #62, I shared a new iteration of the patch series, which uses glob instead of regexp. I see no security issue with glob, since a pattern like /opt/kata/bin/../../../usr/bin/ls is not a valid match for glob pattern /opt/kata/bin/*. As mentioned in comment #11, this was my first choice, but for (very invalid) reasons I first shared an implementation using regexps.
Do you object to using glob patterns? They are pretty familiar to any Unix sysadmin IMO.
> Christophe, looks like you are running a rootless
> container there with podman(I'll let you confirm),
> which explains the permissions issue, whereas
> containers launched with k8s are launched as root.
I'm running podman as root, if that's what you are asking.
However, even in that case, the container root user is
not host uid 0, but uses namespaces to map that to some
other user. This is the reason of the failure above.
Apparently, the behavior reported for k8s does not happen with OpenShift either. OpenShift, like podman, blocks this particular form of attack. I suspect it would be possible to achieve a similar result with a privileged container, however.
> I mentioned this as a way to get rid of regular
> expressions in the configuration.
In comment #62, I shared a new iteration of the patch series, which uses glob instead of regexp. I see no security issue with glob, since a pattern like /opt/kata/ bin/../ ../../usr/ bin/ls is not a valid match for glob pattern /opt/kata/bin/*. As mentioned in comment #11, this was my first choice, but for (very invalid) reasons I first shared an implementation using regexps.
Do you object to using glob patterns? They are pretty familiar to any Unix sysadmin IMO.