I'm running rsync (over ssh) to backup files from servers with a later release Fedora (24, 27, and 28) to my server which is Fedora 22. Some of the files copied have file contexts that aren't available on my server which creates errors (the source, bb8, is Fedora 27; /bacula is just the target mountpoint): [0:root@elmo testing 23]$ rsync --delete -axAXv -e "ssh -p 22" "rsync://bb8.example.com/etc/" /bacula/clients/etc/bb8/ receiving incremental file list rsync: rsync_xal_set: lsetxattr(""/bacula/clients/etc/bb8/udev/hwdb.bin"","security.selinux") failed: Invalid argument (22)
Since this is strictly for backups, I would like to allow rsync to set these unknown contexts. The AVC: type=AVC msg=audit(1555319931.042:30687): avc: denied { mac_admin } for pid=7061 comm="rsync" 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
Running: grep rsync /var/log/audit/audit.log | audit2allow -m my_rsync > my_rsync.te generates: module my_rsync 1.0; require { type unconfined_t; class capability2 mac_admin; } #============= unconfined_t ============== allow unconfined_t self:capability2 mac_admin;
This should work however I don't want to grant this to any program except rsync. I've looked the rsync booleans and tried "setsebool -P rsync_client 1" but it doesn't fix it. Searched the interwebs too.
Can anyone help?
[0:root@elmo rsync 130]$ rpm -q rsync rsync-3.1.1-7.fc22.x86_64 [0:root@elmo rsync]$ ls -lZ `which rsync` -rwxr-xr-x. 1 root root system_u:object_r:rsync_exec_t:s0 495792 Jan 8 2016 /usr/bin/rsync
Bill
On Mon, Apr 15, 2019 at 5:53 AM Bill shirley bill@bigcdrugs.biz wrote:
I'm running rsync (over ssh) to backup files from servers with a later release Fedora (24, 27, and 28) to my server which is Fedora 22.
I know I'm not telling you anything you don't already know, but: security updates have ceased for Fedora 27 and earlier. Fedora 22 hasn't received security updates since summer 2017.
Since this is strictly for backups, I would like to allow rsync to set these unknown contexts. The AVC:
type=AVC msg=audit(1555319931.042:30687): avc: denied { mac_admin } for pid=7061 comm="rsync" 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
Running:
grep rsync /var/log/audit/audit.log | audit2allow -m my_rsync > my_rsync.te
generates: module my_rsync 1.0; require { type unconfined_t; class capability2 mac_admin; } #============= unconfined_t ============== allow unconfined_t self:capability2 mac_admin;
This should work however I don't want to grant this to any program except rsync. I've looked the rsync booleans and tried "setsebool -P rsync_client 1" but it doesn't fix it. Searched the interwebs too.
The problem you're running into is that you are executing an rsync server as a regular user (via an ssh login), instead of starting an rsync server via, say, systemd.
By default, pam_selinux.so (which sshd calls) transitions all logins (via any mechanism, not just sshd) to unconfined_t:
$ semanage login -l
Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 * system_u system_u s0-s0:c0.c1023 *
By design, a process running in unconfined_t has very few state transitions that permit it to transition out of unconfined_t.
I don't want to grant this to any program except rsync
That's not how SELinux works. A particular program can trigger a domain transition, but you don't grant capabilities to a program. You grant them to domains.
Probably the simplest thing you could do here would be something like this:
$ semanage login -a -s staff_u backup_account
With this mapping place, logging in to the server as the backup_account user will result in the login session having the staff_u:staff_r:staff_t context, instead of the unconfined_u:unconfined_r:unconfined_t context. That way, you can use staff_t in your custom SELinux policy module (above), instead of unconfined_t.
But beware: domains that are not unconfined_t are locked down much more heavily than unconfined_t is. You might find that while putting the account that is receiving the rsync-over-ssh into staff_t (or user_t) solves the immediate problem, it requires you to create all sorts of additional rules to permit the rsync server, running in staff_t or user_t, to do things that it could do without issue when it was running in the unconfined_t domain.
Thanks for your informative reply. I learned a little bit more about selinux.
I played around with 'runcon' but then got lots of AVCs just like you noted. At this point, it's not worth pursuing.
Bill
On 4/15/2019 4:38 PM, James Ralston wrote:
On Mon, Apr 15, 2019 at 5:53 AM Bill shirley bill@bigcdrugs.biz wrote:
I'm running rsync (over ssh) to backup files from servers with a later release Fedora (24, 27, and 28) to my server which is Fedora 22.
I know I'm not telling you anything you don't already know, but: security updates have ceased for Fedora 27 and earlier. Fedora 22 hasn't received security updates since summer 2017.
Since this is strictly for backups, I would like to allow rsync to set these unknown contexts. The AVC:
type=AVC msg=audit(1555319931.042:30687): avc: denied { mac_admin } for pid=7061 comm="rsync" 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
Running:
grep rsync /var/log/audit/audit.log | audit2allow -m my_rsync > my_rsync.te
generates: module my_rsync 1.0; require { type unconfined_t; class capability2 mac_admin; } #============= unconfined_t ============== allow unconfined_t self:capability2 mac_admin;
This should work however I don't want to grant this to any program except rsync. I've looked the rsync booleans and tried "setsebool -P rsync_client 1" but it doesn't fix it. Searched the interwebs too.
The problem you're running into is that you are executing an rsync server as a regular user (via an ssh login), instead of starting an rsync server via, say, systemd.
By default, pam_selinux.so (which sshd calls) transitions all logins (via any mechanism, not just sshd) to unconfined_t:
$ semanage login -l
Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 * system_u system_u s0-s0:c0.c1023 *
By design, a process running in unconfined_t has very few state transitions that permit it to transition out of unconfined_t.
I don't want to grant this to any program except rsync
That's not how SELinux works. A particular program can trigger a domain transition, but you don't grant capabilities to a program. You grant them to domains.
Probably the simplest thing you could do here would be something like this:
$ semanage login -a -s staff_u backup_account
With this mapping place, logging in to the server as the backup_account user will result in the login session having the staff_u:staff_r:staff_t context, instead of the unconfined_u:unconfined_r:unconfined_t context. That way, you can use staff_t in your custom SELinux policy module (above), instead of unconfined_t.
But beware: domains that are not unconfined_t are locked down much more heavily than unconfined_t is. You might find that while putting the account that is receiving the rsync-over-ssh into staff_t (or user_t) solves the immediate problem, it requires you to create all sorts of additional rules to permit the rsync server, running in staff_t or user_t, to do things that it could do without issue when it was running in the unconfined_t domain. _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...
selinux@lists.fedoraproject.org