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@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
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@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@redhat.com>
--
Andrea Bolognani / Red Hat / Virtualization
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@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
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@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
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
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
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
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
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
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 :|
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
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
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
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
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/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html 2. https://hg.mozilla.org/mozilla-central/file/tip/security/sandbox/mac/SandboxPolicyContent.h 3. https://source.chromium.org/chromium/chromium/src/+/master:sandbox/policy/mac/common.sb Thanks, Roman
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
© 2016 - 2024 Red Hat, Inc.