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-attributes-xattrs/
2. https://eclecticlight.co/2020/01/07/diagnosing-privacy-protection-problems-in-catalina/
3. https://eclecticlight.co/2020/01/30/quarantine-sip-and-macl-macos-per-file-security-controls/
4. https://mjtsai.com/blog/2019/12/18/persistent-file-access-via-com-apple-macl-xattr/
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.auto.html
Thanks,
Roman
