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

[Daniel Walsh <dwalsh@redhat.com>]

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.