On 6/7/19 11:42 AM, Daniel Walsh wrote:
We have periodic vulnerablities around bad container images having symbolic link attacks against the host. One came out last week about doing a `podman cp` Which would copy content from the host into the container. The issue was that if the container was running, it could trick the processes copying content into it to follow a symbolic link to external of the container image. The question came up, is there a way to use SELinux to prevent this. And sadly the answer right now is no, because we have no way to know what the label of the process attempting to update the container file system is running as. Usually it will be running as unconfined_t. One idea would be to add a rule to policy that control the following of symbolic links to only those specified in policy. Something like SPECIALRESTRICTED TYPE container_file_t allow container_file_t container_file_t:symlink follow; Then if a process attempted to copy content onto a symbolic link from container_file_t to a non container_file_t type, the kernel would deny access. Thoughts?
SELinux would prevent it if you didn't allow unconfined_t (or other privileged domains) to follow untrustworthy symlinks (e.g. don't allow unconfined_t container_file_t:lnk_file read; in the first place). That's the right way to prevent it.
Trying to apply a check between symlink and its target as you suggest is problematic; we don't generally have them both at the same point. If we are allowed to follow the symlink, we read its contents and perform a path walk on that, and that could be a multi-component pathname lookup that itself spans further symlinks, mount points, etc. I think that would be challenging to support in the kernel, subject to races, and certainly would require changes outside of just SELinux.
If you truly cannot impose such restrictions on unconfined_t, then maybe podman should run in its own domain.
