On 12/13/18 1:54 PM, Vivek Goyal wrote:
On Thu, Dec 13, 2018 at 11:12:31AM -0500, Stephen Smalley wrote:
[..]
Can you elaborate a bit more on how this is leaking data through overlay
mount. If it is, then why accessing file on lower is not equivalent of
leaking of data.
In the container use case, retaining the lower label on copy-up for a
context-mounted overlay permits a process in the container to leak the
container data out to host files not labeled with the container label and
thus potentially accessible to other containers or host processes.
The
container process appears to just be writing to files labeled with the
container label via the overlay, but the written data and/or metadata is
directly accessible through the lower label, which is likely readable to
all/many containers and host processes.
In the multi-level security (MLS) use case, an analogy would a situation
where you have an unclassified lower dir with some content to be shared
read-only across all levels, and an overlay is context-mounted at each level
with a corresponding upper dir and work dir private to that level. If a
client process at secret performs a write to a file via the secret overlay,
and if the written data is stored in a file in the upper dir that inherits
the label from the lower file (unclassified), then the secret process can
leak data to unclassified processes at will, violating the MLS policy.
For the case of devices, its already happening. One might change metadata
of a device (hence trigger copy up). Now all writes to upper device file
from secret process still go to same underlying device and are still
readable from lower device file.
This is an argument for not copying up device files IMHO, not for preserving
the lower label on them.
How do we handle metadata change to device node (like timestamp, ownership
change) without copy up.
Do we need to support such metadata changes to device nodes through an
overlay mount? Is that required for some legitimate purpose (and if so,
what is the use case?)? If not, just deny it up front. Much simpler
and no potential for a leak.
