On 6/7/19 12:44 PM, Stephen Smalley wrote: > 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. > This is not an issue with just podman. Podman can mount the image and the tools can just read/write content into the mountpoint. I thought I recalled a LSM that prefented symlink attacks when users would link a file in the homedir against /etc/shadow and then attempt to get the admin to modify the file in his homedir? I was thinking that if that existed we could build more controls on it based on Labels rather then just UIDs matching.
