On Thu, Oct 29, 2020 at 07:28:23PM +0100, Michal Privoznik wrote:
On 10/29/20 6:56 PM, Andrea Bolognani wrote:
> On Thu, 2020-10-29 at 15:23 +0100, Michal Privoznik wrote:
> > On 10/29/20 2:36 PM, Andrea Bolognani wrote:
> > > 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.
>
> Based on the understanding of the situation that I've gained through
> your very detailed explanations (thanks!), I would say that by doing
> so we'd only be papering over the issue: when actually starting
> guests on macOS, we'd still attempt to store the original owner in
> xattrs and fail, right?
I don't think we would fail. My assumption is that macOS has no notion of
namespaces and XATTRs can be manipulated by anybody (well, the owner of the
file + root). So we would not fail but create a huge security hole. But then
again, it all boils down to still unanswered question, how does macOS handle
XATTRs and whether there is a namespace we can safely use.
Roman, can you chime in? We could really use your input here.
Hi Michal,
First of all thank you for catching up the issue. I'm sorry I didn't
join the thread earlier and didn't provide you with more with more
background with regards to apple implementation of xattrs. TBH I haven't
completed the investigation yet but I wanted both to solicit for
feedback and fix the tests, so I rushed a bit:) Perhaps, next time it's
worth to add RFC tag.
Apple is using xattrs to store metadata [1] and for security features of
the OS [2][3][4][5], like quarantine. And from the user experience I
know that each app may be restricted access to certain locations, i.e.
it's possible to restrict access to ~/Downloads directory to shell
running in Terminal app. I can investigate if the features are
sufficient to implement libvirt security model.
BTW, I doubt someone will run libvirt under root though. Homebrew
provides launchd [6] wrapper to start libvirtd under current user:
brew services start libvirt
With regards to system xattr namespace, I've just found
"com.apple.system." in xnu kernel code [7]:
/*
* Determine whether an EA is a protected system attribute.
*/
int
xattr_protected(const char *attrname)
{
return !strncmp(attrname, "com.apple.system.", 17);
}
I don't know yet if it can be used by libvirt. I'll look into it.
1.
https://eclecticlight.co/2017/12/11/an-introduction-to-extended-attribute...
2.
https://eclecticlight.co/2020/01/07/diagnosing-privacy-protection-problem...
3.
https://eclecticlight.co/2020/01/30/quarantine-sip-and-macl-macos-per-fil...
4.
https://mjtsai.com/blog/2019/12/18/persistent-file-access-via-com-apple-m...
5.
https://developer.apple.com/forums/thread/124121
5.
https://developer.apple.com/videos/play/wwdc2019/701/
6.
https://www.launchd.info
7.
https://opensource.apple.com/source/xnu/xnu-6153.81.5/bsd/vfs/vfs_xattr.c...
Thanks,
Roman