New Container vulnerability could potentially use an SELinux fix.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?







[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux