Re: New Container vulnerability could potentially use an SELinux fix.

[Daniel Walsh <dwalsh@redhat.com>]

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.
>