lsetxattr failed, SELINUX_ERR op=setxattr invalid_context

[Chris Murphy]

Hi,

I'm running Fedora 35, and I'm trying to replicate a Fedora 36 root snapshot from
one Btrfs file system to another, but it fails.

This is what I see on CLI (with verbose logging)

set_xattr etc/NetworkManager/dispatcher.d - name=security.selinux data_len=56
data=system_u:object_r:NetworkManager_dispatcher_script_t:s0
ERROR: lsetxattr etc/NetworkManager/dispatcher.d
security.selinux=system_u:object_r:NetworkManager_dispatcher_script_t:s0 failed: Invalid
argument

This is the AVC error:

[25325.074972] audit[23509]: AVC avc:  denied  { mac_admin } for  pid=23509
comm="btrfs" capability=33 
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=capability2
permissive=0
[25325.075188] audit: SELINUX_ERR op=setxattr
invalid_context="system_u:object_r:NetworkManager_dispatcher_script_t:s0"


I think what's going on is, Fedora 35's SELinux is preventing `btrfs receive` from
setting a label it doesn't know. If so, is this definitely the correct behavior? Or is
there something `btrfs receive`
could do to allow setting this unfamiliar label anyway, or is this an unacceptable risk to
set arbitrary labels?

I filed a btrfs-progs bug, feel free to answer there (or here)
https://github.com/kdave/btrfs-progs/issues/447

Thanks,

-- 
Chris Murphy

[Zdenek Pytela]

On Wed, Feb 9, 2022 at 12:16 AM Chris Murphy <lists(a)colorremedies.com&gt;
wrote:

>  Hi,
>
>  I'm running Fedora 35, and I'm trying to replicate a Fedora 36 root
>  snapshot from one Btrfs file system to another, but it fails.
>
>  This is what I see on CLI (with verbose logging)
>
>  set_xattr etc/NetworkManager/dispatcher.d - name=security.selinux
>  data_len=56 data=system_u:object_r:NetworkManager_dispatcher_script_t:s0
>  ERROR: lsetxattr etc/NetworkManager/dispatcher.d
>  security.selinux=system_u:object_r:NetworkManager_dispatcher_script_t:s0
>  failed: Invalid argument
>
>  This is the AVC error:
>
>  [25325.074972] audit[23509]: AVC avc:  denied  { mac_admin } for
>  pid=23509 comm="btrfs" capability=33
>  scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>  tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>  tclass=capability2 permissive=0
>  [25325.075188] audit: SELINUX_ERR op=setxattr
>  invalid_context="system_u:object_r:NetworkManager_dispatcher_script_t:s0"
>
>
>  I think what's going on is, Fedora 35's SELinux is preventing `btrfs
>  receive` from setting a label it doesn't know. If so, is this definitely
>  the correct behavior? Or is there something `btrfs receive`
>  could do to allow setting this unfamiliar label anyway, or is this an
>  unacceptable risk to set arbitrary labels?
>  
Hi,

I cannot speak for btrfs, but from SELinux PoV this seems to be correct:
When a file is restored including extended attributes and the SELinux type
is not known, it should fail, probably unlabeled_t will be seen there. If
there is no better solution, I'd go with not setting labels at all and
restore them later using

fixfiles onboot -F



>  I filed a btrfs-progs bug, feel free to answer there (or here)
>  https://github.com/kdave/btrfs-progs/issues/447
>
>  Thanks,
>
>  --
>  Chris Murphy
>  _______________________________________________
>  selinux mailing list -- selinux(a)lists.fedoraproject.org
>  To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  

-- 

Zdenek Pytela
Security SELinux team

[Chris Murphy]

On Wed, Feb 9, 2022 at 9:24 AM Zdenek Pytela <zpytela(a)redhat.com&gt; wrote:
>  On Wed, Feb 9, 2022 at 12:16 AM Chris Murphy <lists(a)colorremedies.com&gt; wrote:
> >
> > Hi,
> >
> > I'm running Fedora 35, and I'm trying to replicate a Fedora 36 root snapshot
> from one Btrfs file system to another, but it fails.
> >
> > This is what I see on CLI (with verbose logging)
> >
> > set_xattr etc/NetworkManager/dispatcher.d - name=security.selinux data_len=56
> data=system_u:object_r:NetworkManager_dispatcher_script_t:s0
> > ERROR: lsetxattr etc/NetworkManager/dispatcher.d
> security.selinux=system_u:object_r:NetworkManager_dispatcher_script_t:s0 failed: Invalid
> argument
> >
> > This is the AVC error:
> >
> > [25325.074972] audit[23509]: AVC avc:  denied  { mac_admin } for  pid=23509
> comm="btrfs" capability=33 
> scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=capability2
> permissive=0
> > [25325.075188] audit: SELINUX_ERR op=setxattr
> invalid_context="system_u:object_r:NetworkManager_dispatcher_script_t:s0"
> >
> >
> > I think what's going on is, Fedora 35's SELinux is preventing `btrfs receive`
> from setting a label it doesn't know. If so, is this definitely the correct behavior?
> Or is there something `btrfs receive`
> > could do to allow setting this unfamiliar label anyway, or is this an unacceptable
> risk to set arbitrary labels?
>
>  Hi,
>
>  I cannot speak for btrfs, but from SELinux PoV this seems to be correct: When a file is
> restored including extended attributes and the SELinux type is not known, it should fail,
> probably unlabeled_t will be seen there. If there is no better solution, I'd go with
> not setting labels at all and restore them later using
>
>  fixfiles onboot -F 
Yep, it's a question of which consequences to go with :)

The command is:
# btrfs send $snapshot | btrfs receive $path

The send portion produces a stream, which does contain xattr, which
includes SELinux labels. And it's up to receive to preserve everything
in the stream, or else error and fail because ostensibly the concept
of send|receive is snapshot replication. And if xattr are missing in
the destination, the snapshot isn't really replicated. The receive
subcommand has a flag -E0 which means to ignore all errors and receive
anyway. So it can be received, but the "received UUID" is not set on
the replicated snapshot because it's not an exact copy, so we're
unable to do incremental receive without "received UUID".

So it's an interesting dilemma.



-- 
Chris Murphy

[Chris Murphy]

On Wed, Feb 9, 2022 at 9:24 AM Zdenek Pytela <zpytela(a)redhat.com&gt; wrote:
>  On Wed, Feb 9, 2022 at 12:16 AM Chris Murphy <lists(a)colorremedies.com&gt; wrote:
> >
> > Hi,
> >
> > I'm running Fedora 35, and I'm trying to replicate a Fedora 36 root snapshot
> from one Btrfs file system to another, but it fails.
> >
> > This is what I see on CLI (with verbose logging)
> >
> > set_xattr etc/NetworkManager/dispatcher.d - name=security.selinux data_len=56
> data=system_u:object_r:NetworkManager_dispatcher_script_t:s0
> > ERROR: lsetxattr etc/NetworkManager/dispatcher.d
> security.selinux=system_u:object_r:NetworkManager_dispatcher_script_t:s0 failed: Invalid
> argument
> >
> > This is the AVC error:
> >
> > [25325.074972] audit[23509]: AVC avc:  denied  { mac_admin } for  pid=23509
> comm="btrfs" capability=33 
> scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=capability2
> permissive=0
> > [25325.075188] audit: SELINUX_ERR op=setxattr
> invalid_context="system_u:object_r:NetworkManager_dispatcher_script_t:s0"
> >
> >
> > I think what's going on is, Fedora 35's SELinux is preventing `btrfs receive`
> from setting a label it doesn't know. If so, is this definitely the correct behavior?
> Or is there something `btrfs receive`
> > could do to allow setting this unfamiliar label anyway, or is this an unacceptable
> risk to set arbitrary labels?
>
>  Hi,
>
>  I cannot speak for btrfs, but from SELinux PoV this seems to be correct: When a file is
> restored including extended attributes and the SELinux type is not known, it should fail,
> probably unlabeled_t will be seen there. If there is no better solution, I'd go with
> not setting labels at all and restore them later using
>
>  fixfiles onboot -F
>  
Since a received btrfs snapshot is read-only by design, we can't run
fixfiles on it. But further, since the receive snapshot is intended to
be a fully replicated copy of the original on the send side, the data
and metadata ostensibly need to be the same before it can be
considered "received" for the purpose of subsequent incremental
send|receive tasks.

What about backporting new security labels to older versions of
Fedora, even if they aren't used? Seems to me the security label is
legitimate regardless of whether it's actively used on the older
version of Fedora. It would just be a means to an end, to ensure the
successful replication of data.



-- 
Chris Murphy