send|receive ERROR: lsetxattr failed, SELINUX_ERR op=setxattr invalid_context

[cmurf]

Problem: When doing send|receive with a source snapshot that contains unsupported SELinux labels on the host: (a) the receive fails (b) using -E0 option permits successful receive but "received UUID" is not set.

Arguably (b) is correct behavior, in that we don't want to say something is successfully received if it's not actually fully replicated, including xattr. But is there something that btrfs send/receive can do to (force) set the label anyway? Or is there a legitimate reason for SELinux to prevent btrfs receive from setting what it thinks are arbitrary labels?

mkdir o440-12-0
rename o440-12-0 -> etc/NetworkManager/dispatcher.d
utimes etc/NetworkManager
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

With -E0, the receive succeeds but the label is not set:

# ls -lZ 
drwxr-xr-x. 1 root root unconfined_u:object_r:default_t:s0             54 Feb  4 11:30 dispatcher.d

AVC denial is reported.

time->Tue Feb  8 15:25:29 2022
type=AVC msg=audit(1644359129.442:660): avc:  denied  { mac_admin } for  pid=22688 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

Full journal entry for the event:

[25325.044607] sudo[23506]:    chris : TTY=pts/2 ; PWD=/home/chris ; USER=root ; COMMAND=/usr/sbin/btrfs send /media/root.20220208-clean/
[25325.046975] sudo[23507]:    chris : TTY=pts/2 ; PWD=/home/chris ; USER=root ; COMMAND=/usr/sbin/btrfs receive /mnt
[25325.050995] sudo[23506]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
[25325.052041] audit[23506]: USER_START pid=23506 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/2 res=success'
[25325.052193] audit[23507]: USER_START pid=23507 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/2 res=success'
[25325.052324] sudo[23507]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
[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"

The use case is to replicate an updated root file system. I'm trying to upgrade from 35 to 36, while running 35, using a snapshot of 36.

btrfs-progs-5.16.1-1.fc35.x86_64 kernel-5.16.5-200.fc35.x86_64 selinux-policy-35.13-1.fc35.noarch

[cmurf]

Posted inquiry to selinux@lists.fedoraproject.org https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/thread/YTGX66CCJLDVMFFOGBV2CUS637NCAQR6/

[cmurf]

Perhaps another possibility is backporting new security labels to older release versions of a distribution, so that the receive command can fully succeed.

[zatricky]

How I came across this bug: I have some new backups using btrbk that were failing because of new selinux labels that weren't supported on the backup server. The "workaround" was to synchronise the installstate of those offending packages on the backup server* even though those packages are otherwise unnecessary on the backup server.

A good fix is for selinux to have some mechanism to allow the backup (and restore) to succeed cleanly without any extra steps on btrfs' part - even if the server doesn't understand the contexts - but I don't think that will happen any time soon. :-/

It'd be convenient if btrfs-progs made it easy to ignore this problem with an --ignore-setxattr-invalid-context type flag. A full relabel isn't such a bad extra step if restoring a server from backup - as long as you're aware of it of course!

* this also necessitated doing a dnf system-upgrade on the backup server a bit earlier than planned. 🤪

[unterkomplex]

For anyone who struggles with allowing access in SELinux as I did:

1. Install setroubleshoot package (dnf install setroubleshoot or similar)
2. Execute the btrfs send command that fails due to lsetxattr again
3. You should see a system log like this setroubleshoot[...]: SELinux is preventing btrfs from [...]
4. The next few lines of the system log explain how to allow btrfs to execute the lsetxattr (execute as root)

   # ausearch -c 'btrfs' --raw | audit2allow -M my-btrfs
   # semodule -X 300 -i my-btrfs.pp

Now you should be able to rerun btrfs send without issues

[JavkhlanK]

another plain, temporary fix is to just set SELinux to permissive mode (kinda obviously lol)