On 6/7/19 5:26 PM, Stephen Smalley wrote: > On 6/7/19 5:06 PM, Daniel Walsh wrote: >> 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. > > Not sure if you are thinking of symlink attacks or hard link attacks. > SELinux supports preventing the former by restricting the ability to > follow symlinks based on lnk_file read permission, so you can prevent > trusted processes from following untrustworthy symlinks. SELinux > supports preventing the latter by restricting the ability to create > hard links to unauthorized files. But you need to write your policies > in a manner that leverages that support, and a fully unconfined domain > isn't going to be protected via SELinux by definition; ideally you'd > be phasing out unconfined altogether like Android did. Modern kernels > also have the /proc/sys/fs/protected_hardlinks and > /proc/sys/fs/protected_symlinks settings, which restrict based on UID, > but the symlink checks aren't based on the target of the symlink either. Android does not have an Admin, so it is a lot easier for them. But not going to get into that now. I obviously understand how SELinux works. But perhaps I am looking for something differntly. This link defines pretty close to what I would want, but extended for labels rather then just UIDS. https://sysctl-explorer.net/fs/protected_symlinks/ > A long-standing class of security issues is the symlink-based > time-of-check-time-of-use race, most commonly seen in world-writable > directories like /tmp. The common method of exploitation of this flaw > is to cross privilege boundaries when following a given symlink (i.e. > a **PRIVILEGED** process follows a symlink belonging **PROVIDED BY > OTHERS**). For a likely incomplete list of hundreds of examples across > the years, please see: > http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp > > When set to “0”, symlink following behavior is unrestricted. > > When set to “1” symlinks are permitted to be followed only when > outside a sticky world-writable directory **WE COULD POTENTIALLY SET > THIS OR SOME OTHER FLAG**, or when the **LABEL** of the symlink and > follower match, or when the directory **LABEL** matches the symlink’s > **LABEL**. > > This protection is based on the restrictions in Openwall and grsecurity. >
