10:25 p.m.
There're no guidelines on what namespace should be used but it seems
thirdparty apps can select the one they like [1], i.e. freedekstop
xattrs are prefixed with xdg.
qemusecuritytest passes after that.
1. https://www.freedesktop.org/wiki/CommonExtendedAttributes/
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
src/security/security_util.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/security/security_util.c b/src/security/security_util.c
index 7fa5163fe4..5d50acb574 100644
--- a/src/security/security_util.c
+++ b/src/security/security_util.c
@@ -56,6 +56,8 @@ VIR_LOG_INIT("security.security_util");
# define XATTR_NAMESPACE "trusted"
#elif defined(__FreeBSD__)
# define XATTR_NAMESPACE "system"
+#elif defined(__APPLE__)
+# define XATTR_NAMESPACE "org"
#endif
static char *
--
2.28.0
8:16 p.m.
On Mon, 2020-10-26 at 00:25 +0300, Roman Bolshakov wrote:
There're no guidelines on what namespace should be used but it
seems
thirdparty apps can select the one they like [1], i.e. freedekstop
xattrs are prefixed with xdg.
qemusecuritytest passes after that.
1. https://www.freedesktop.org/wiki/CommonExtendedAttributes/
Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
---
src/security/security_util.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/security/security_util.c b/src/security/security_util.c
index 7fa5163fe4..5d50acb574 100644
--- a/src/security/security_util.c
+++ b/src/security/security_util.c
@@ -56,6 +56,8 @@ VIR_LOG_INIT("security.security_util");
# define XATTR_NAMESPACE "trusted"
#elif defined(__FreeBSD__)
# define XATTR_NAMESPACE "system"
+#elif defined(__APPLE__)
+# define XATTR_NAMESPACE "org"
#endif
Considering that Apple uses com.apple for its own xattrs, libvirt
using org.libvirt makes sense to me.
Reviewed-by: Andrea Bolognani <abologna(a)redhat.com>
--
Andrea Bolognani / Red Hat / Virtualization
8:25 p.m.
On 10/28/20 8:16 PM, Andrea Bolognani wrote:
On Mon, 2020-10-26 at 00:25 +0300, Roman Bolshakov wrote:
> There're no guidelines on what namespace should be used but it seems
> thirdparty apps can select the one they like [1], i.e. freedekstop
> xattrs are prefixed with xdg.
>
> qemusecuritytest passes after that.
>
> 1. https://www.freedesktop.org/wiki/CommonExtendedAttributes/
>
> Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
> ---
> src/security/security_util.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/security/security_util.c b/src/security/security_util.c
> index 7fa5163fe4..5d50acb574 100644
> --- a/src/security/security_util.c
> +++ b/src/security/security_util.c
> @@ -56,6 +56,8 @@ VIR_LOG_INIT("security.security_util");
> # define XATTR_NAMESPACE "trusted"
> #elif defined(__FreeBSD__)
> # define XATTR_NAMESPACE "system"
> +#elif defined(__APPLE__)
> +# define XATTR_NAMESPACE "org"
> #endif
Considering that Apple uses com.apple for its own xattrs, libvirt
using org.libvirt makes sense to me.
One thing to consider here (and my rough googling did not help) is that
we need the namespace to be RW only by root. If it were writable by a
regular user (e.g "user." on linux) then a regular user could trick us
to chown() the file to whatever user they please. Is "org" (and per your
commit message in fact any XATTR namespace, since it doesn't look like
mac os has any notion of namespaces after all) writable by root only?
Michal
11:49 a.m.
On Wed, 2020-10-28 at 20:25 +0100, Michal Privoznik wrote:
On 10/28/20 8:16 PM, Andrea Bolognani wrote:
> On Mon, 2020-10-26 at 00:25 +0300, Roman Bolshakov wrote:
> > +++ b/src/security/security_util.c
> > @@ -56,6 +56,8 @@ VIR_LOG_INIT("security.security_util");
> > # define XATTR_NAMESPACE "trusted"
> > #elif defined(__FreeBSD__)
> > # define XATTR_NAMESPACE "system"
> > +#elif defined(__APPLE__)
> > +# define XATTR_NAMESPACE "org"
> > #endif
>
> Considering that Apple uses com.apple for its own xattrs, libvirt
> using org.libvirt makes sense to me.
One thing to consider here (and my rough googling did not help) is that
we need the namespace to be RW only by root. If it were writable by a
regular user (e.g "user." on linux) then a regular user could trick us
to chown() the file to whatever user they please. Is "org" (and per your
commit message in fact any XATTR namespace, since it doesn't look like
mac os has any notion of namespaces after all) writable by root only?
Yeah that's a solid point, thanks for keeping an eye on me ;)
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?
--
Andrea Bolognani / Red Hat / Virtualization
12:18 p.m.
On 10/29/20 11:49 AM, Andrea Bolognani wrote:
On Wed, 2020-10-28 at 20:25 +0100, Michal Privoznik wrote:
> On 10/28/20 8:16 PM, Andrea Bolognani wrote:
>> On Mon, 2020-10-26 at 00:25 +0300, Roman Bolshakov wrote:
>>> +++ b/src/security/security_util.c
>>> @@ -56,6 +56,8 @@ VIR_LOG_INIT("security.security_util");
>>> # define XATTR_NAMESPACE "trusted"
>>> #elif defined(__FreeBSD__)
>>> # define XATTR_NAMESPACE "system"
>>> +#elif defined(__APPLE__)
>>> +# define XATTR_NAMESPACE "org"
>>> #endif
>>
>> Considering that Apple uses com.apple for its own xattrs, libvirt
>> using org.libvirt makes sense to me.
>
> One thing to consider here (and my rough googling did not help) is that
> we need the namespace to be RW only by root. If it were writable by a
> regular user (e.g "user." on linux) then a regular user could trick us
> to chown() the file to whatever user they please. Is "org" (and per your
> commit message in fact any XATTR namespace, since it doesn't look like
> mac os has any notion of namespaces after all) writable by root only?
Yeah that's a solid point, thanks for keeping an eye on me ;)
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.
Michal
2:36 p.m.
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.
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?
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 :)
--
Andrea Bolognani / Red Hat / Virtualization
2:40 p.m.
On Thu, Oct 29, 2020 at 02:36:42PM +0100, 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.
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?
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.
Windows is irrelevant since none of the QEMU code builds there.
With did without xattrs in Linux for 10 years. The problem xattrs
solve is restoring the file ownership back to the original owner,
instead of hardcoding it as "root".
If xattrs can be modified by non-root user though, then use of
xattrs is a *massive* security hole you can drive a tank through
and must *not* be enabled.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
3:23 p.m.
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
6:56 p.m.
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? So I think on macOS we need to always behave
as if remember_owner had been set to 0 in qemu.conf.
--
Andrea Bolognani / Red Hat / Virtualization
7:28 p.m.
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.
So I think on macOS we need to always behave
as if remember_owner had been set to 0 in qemu.conf.
This should be working like that already.
Michal
9:02 p.m.
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
1:40 p.m.
On Thu, Oct 29, 2020 at 03:23:46PM +0100, Michal Privoznik wrote:
On 10/29/20 2:36 PM, Andrea Bolognani wrote:
> On Thu, 2020-10-29 at 12:18 +0100, Michal Privoznik wrote:
>
> 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
But if you don't run libvirt under root, would there be an issue?
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)?
There's no notion of CAP_SYS_ADMIN and zones/jails/namespaces on macOS.
The closest equivalent of Linux namespaces with regards to security are
app sandboxes [1]. It's possible to write sophisticated Lisp-like rules
that restrict an app as much as possible, then run it in a sandbox with
the rules provided. Apple's applications, Firefox [3] and Chromium [4]
heavily use the feature.
1.
https://developer.apple.com/library/archive/documentation/Security/Concep...
2.
https://hg.mozilla.org/mozilla-central/file/tip/security/sandbox/mac/Sand...
3.
https://source.chromium.org/chromium/chromium/src/+/master:sandbox/policy...
Thanks,
Roman
12:47 p.m.
On Thu, Oct 29, 2020 at 12:18:13PM +0100, Michal Privoznik wrote:
On 10/29/20 11:49 AM, Andrea Bolognani wrote:
> On Wed, 2020-10-28 at 20:25 +0100, Michal Privoznik wrote:
> > On 10/28/20 8:16 PM, Andrea Bolognani wrote:
> > > On Mon, 2020-10-26 at 00:25 +0300, Roman Bolshakov wrote:
> > > > +++ b/src/security/security_util.c
> > > > @@ -56,6 +56,8 @@ VIR_LOG_INIT("security.security_util");
> > > > # define XATTR_NAMESPACE "trusted"
> > > > #elif defined(__FreeBSD__)
> > > > # define XATTR_NAMESPACE "system"
> > > > +#elif defined(__APPLE__)
> > > > +# define XATTR_NAMESPACE "org"
> > > > #endif
> > >
> > > Considering that Apple uses com.apple for its own xattrs, libvirt
> > > using org.libvirt makes sense to me.
> >
> > One thing to consider here (and my rough googling did not help) is that
> > we need the namespace to be RW only by root. If it were writable by a
> > regular user (e.g "user." on linux) then a regular user could trick
us
> > to chown() the file to whatever user they please. Is "org" (and per
your
> > commit message in fact any XATTR namespace, since it doesn't look like
> > mac os has any notion of namespaces after all) writable by root only?
>
> Yeah that's a solid point, thanks for keeping an eye on me ;)
>
> 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?
>
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.
I don't see misbehaviour. I was just trying to fix tests :) I want to
resend my old patch series that supports additional accels and I was
asked to fix tests and syntax check first. It turned out to be bigger
issue than the patch series but we're almost at the point of one failing
test and not yet working qemucapsprobe.
Thanks,
Roman
12:38 p.m.
On Wed, Oct 28, 2020 at 08:25:46PM +0100, Michal Privoznik wrote:
On 10/28/20 8:16 PM, Andrea Bolognani wrote:
> On Mon, 2020-10-26 at 00:25 +0300, Roman Bolshakov wrote:
> > There're no guidelines on what namespace should be used but it seems
> > thirdparty apps can select the one they like [1], i.e. freedekstop
> > xattrs are prefixed with xdg.
> >
> > qemusecuritytest passes after that.
> >
> > 1. https://www.freedesktop.org/wiki/CommonExtendedAttributes/
> >
> > Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com>
> > ---
> > src/security/security_util.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/src/security/security_util.c b/src/security/security_util.c
> > index 7fa5163fe4..5d50acb574 100644
> > --- a/src/security/security_util.c
> > +++ b/src/security/security_util.c
> > @@ -56,6 +56,8 @@ VIR_LOG_INIT("security.security_util");
> > # define XATTR_NAMESPACE "trusted"
> > #elif defined(__FreeBSD__)
> > # define XATTR_NAMESPACE "system"
> > +#elif defined(__APPLE__)
> > +# define XATTR_NAMESPACE "org"
> > #endif
>
> Considering that Apple uses com.apple for its own xattrs, libvirt
> using org.libvirt makes sense to me.
>
One thing to consider here (and my rough googling did not help) is that we
need the namespace to be RW only by root. If it were writable by a regular
user (e.g "user." on linux) then a regular user could trick us to chown()
the file to whatever user they please. Is "org" (and per your commit message
in fact any XATTR namespace, since it doesn't look like mac os has any
notion of namespaces after all) writable by root only?
After investigation of xnu kernel, I've found com.apple.system namespace
that can be used to store system attributes but it can't be
set/received/listed from userspace.
$ xattr -w com.apple.system.libvirt bar foo
xattr: [Errno 1] Operation not permitted: 'foo'
$ sudo xattr -w com.apple.system.libvirt bar foo
xattr: [Errno 1] Operation not permitted: 'foo
I haven't found any kind of "trusted"/"system" namespace that can
be
used from user-space. But I'm not sure if libvirt on macOS is going to
be used from root, rather from a user account.
The feature the tests exists for is:
https://patchew.org/Libvirt/cover.1544618362.git.mprivozn@redhat.com/
https://www.redhat.com/archives/libvir-list/2019-November/msg00862.html
What do you think if the tests will be skipped on macOS?
Thanks,
Roman
6:12 p.m.
On Sun, 2020-11-01 at 14:38 +0300, Roman Bolshakov wrote:
On Wed, Oct 28, 2020 at 08:25:46PM +0100, Michal Privoznik wrote:
> One thing to consider here (and my rough googling did not help) is that we
> need the namespace to be RW only by root. If it were writable by a regular
> user (e.g "user." on linux) then a regular user could trick us to chown()
> the file to whatever user they please. Is "org" (and per your commit
message
> in fact any XATTR namespace, since it doesn't look like mac os has any
> notion of namespaces after all) writable by root only?
After investigation of xnu kernel, I've found com.apple.system namespace
that can be used to store system attributes but it can't be
set/received/listed from userspace.
$ xattr -w com.apple.system.libvirt bar foo
xattr: [Errno 1] Operation not permitted: 'foo'
$ sudo xattr -w com.apple.system.libvirt bar foo
xattr: [Errno 1] Operation not permitted: 'foo
I haven't found any kind of "trusted"/"system" namespace that can
be
used from user-space.
Okay, so it sounds like we definitely don't want to perform owner
remembering on macOS.
But I'm not sure if libvirt on macOS is going to
be used from root, rather from a user account.
So, it's just qemu:///session on macOS? What happens if you try to
run libvirtd as root instead?
It's great that apparently the scenario that most macOS users are
going to encounter works, but I'm still concerned that we might not
behave reasonably when qemu:///system is tried instead...
The feature the tests exists for is:
https://patchew.org/Libvirt/cover.1544618362.git.mprivozn@redhat.com/
https://www.redhat.com/archives/libvir-list/2019-November/msg00862.html
What do you think if the tests will be skipped on macOS?
... and that skipping this test would just be papering over an actual
issue.
--
Andrea Bolognani / Red Hat / Virtualization
5:26 p.m.
On Mon, Nov 02, 2020 at 06:12:34PM +0100, Andrea Bolognani wrote:
On Sun, 2020-11-01 at 14:38 +0300, Roman Bolshakov wrote:
> But I'm not sure if libvirt on macOS is going to
> be used from root, rather from a user account.
So, it's just qemu:///session on macOS?
Yes, that's what I had been using when I was running libvirt with HVF
patchset... and qemu+ssh:///session
What happens if you try to run libvirtd as root instead?
It can be started ($VAR_PREFIX/run has to be created before first run).
But I didn't use it like that earlier so I can't tell how it behaves.
It's great that apparently the scenario that most macOS users are
going to encounter works, but I'm still concerned that we might not
behave reasonably when qemu:///system is tried instead...
... and that skipping this test would just be papering over an actual
issue.
I hope Michal's changes address that concerns.
Thanks,
Roman
1413
days inactive
1422
days old
15 comments
4 participants
participants (4)
-
Andrea Bolognani -
Daniel P. Berrangé -
Michal Privoznik -
Roman Bolshakov