On 10/29/20 2:36 PM, Andrea Bolognani wrote:
On Thu, 2020-10-29 at 12:18 +0100, Michal Privoznik wrote:
On 10/29/20 11:49 AM, Andrea Bolognani wrote:
Assuming macOS doesn't have any root-only namespaces, can we simply
compile out the feature entirely on that OS? What about other targets
like Windows?
What do you mean by compile out? The whole security_uitl.c is divided
into two parts: the actual implementation if XATTR_NAMESPACE is set
(which is currently only on Linux + BSD) and stubs which do nothing but
report an error.
Then, these internal APIs are called only from the secdrivers which we
don't build on Windows, do we?
Roman, is there any misbehaviour you're seeing? Or is this just porting
the feature to macOS? I'm not against it, I just don't have anywhere to
test it.
The issue Roman is trying to address with this patch is that
qemusecuritytest fails reporting a bunch of
Security Driver error : Extended attributes are not supported on
this system: Function not implemented
messages.
In that case, we should make the test run only on supported OSes.
I'm not very familiar with security drivers but I guess the question
is: are xattrs a critical part of the security story, without which
no isolation is possible at all, or is it conceivable to have
security drivers that provide some amount of protection on macOS even
though they can't go as far as they can on Linux and FreeBSD?
The way seclabel remmebering works is whenever libvirt wants to
chown()/setfilecon() the current owner/SELinux label is recorded into
XATTRs [1] and then on restore we look into these XATTRs and restore to
the owner stored there. With this it is easy to see that if XATTRs were
editable by a regular user it is very simple to trick libvirt into
changing the owner of a file. As easy as:
1) start a vm with /etc/shadow as a disk
2) modify XATTRs so that the original owner recorded is "michal:michal"
3) kill the vm
4) profit
Now, in Linux and BSD XATTRs must have a prefix. In Linux there are four:
* user - can be modified by anybody,
* system - used by ACLs
* security - used by SELinux
* trusted - accessibly by CAP_SYS_ADMIN processes only
and in BSD there are only two:
* user - can be modified by anybody,
* system - accessible by CAP_SYS_ADMIN processes only
That is why on linux we use "trusted" and on BSD we use "system".
Therefore, on any new system we must use something equivalent. What is
the equivalent on macOS? Does it even have namespaces (as in a subset
that is modifiable only by a CAP_SYS_ADMIN process)?
1: In case a file is shared between two or more domains there is also a
refcounter stored in the XATTRs so the second attempt does not
chown()/setfilecon but: a) checks that the target seclabel is the one
the file already has (to prevent cutting off domains already accessing
the file), and b) increments the refcounter. On restore, only the last
one (i.e. refcounter reached zero) actually restores the original owner
and clears all XATTRs we've set.
In the former case we should modify the functions dealing with them
so that they become successful no-ops, in the latter we should
probably do what we do on Windows and not build the security drivers
at all on macOS.
At least that's my current reading of the situation :)
We should probably disable the test on non-Linux && non-BSD. But let's
wait for the answer to my question.
Michal
