3

I have a number of Debian-based systems that get backed up regularly using rsync. For a number of reasons I have had to deploy a small CentOS 7 server, and I want to add it to my backup schedule. It cannot be backed up using rsync over ssh; instead I need to use the rsync daemon.

CentOS has SELinux enabled in enforcing mode so it's set me off on a steep learning curve.

The rsyncd configuration section (simplified)

[root]
    comment = Filesystem
    path = /
    exclude = /proc/*** /run/*** /sys/*** [...]
    read only = yes
    list = yes
    uid = root
    secrets file = [...]
    ignore errors = no
    ignore nonreadable = no
    refuse options = delete

I believe that the process is labelled correctly:

ps -eZ | grep rsync
system_u:system_r:rsync_t:s0    26020 ?        00:00:00 rsync

Initially the attempt to backup via the rsync daemon failed with all sorts of permission errors which I've attributed to SELinux labels. Digging further I found a reference to an SELinux policy that permits the rsync daemon to export all files read-only:

setsebool -P rsync_export_all_ro 1

This results in this set

getsebool -a | grep '^rsync'
rsync_anon_write --> off
rsync_client --> off
rsync_export_all_ro --> on
rsync_full_access --> off

Unfortunately this still doesn't give me access to all files on the system. Specifically I've some files under /var/spool/postfix/private that are unreadable:

rsync: readlink_stat("/var/spool/postfix/private/defer" (in root)) failed: Permission denied (13)
rsync: readlink_stat("/var/spool/postfix/private/trace" (in root)) failed: Permission denied (13)
rsync: readlink_stat("/var/spool/postfix/private/verify" (in root)) failed: Permission denied (13)
rsync: readlink_stat("/var/spool/postfix/private/proxymap" (in root)) failed: Permission denied (13)
...

One sample entry relating to /var/spool/postfix/private from audit2why -a follows. Note that none of the entries references rsync_export_all_ro:

type=AVC msg=audit(1565118203.332:21775): avc:  denied  { getattr } for  pid=26597 comm="rsync" path="/var/spool/postfix/private/scache" dev="dm-0" ino=9148374 scontext=system_u:system_r:rsync_t:s0 tcontext=system_u:object_r:postfix_private_t:s0 tclass=sock_file permissive=0
        Was caused by:
        The boolean rsync_full_access was set incorrectly.
        Description:
        Allow rsync to full access

        Allow access by executing:
        # setsebool -P rsync_full_access 1

I don't understand why there's a reference to rsync_full_access (which I don't want to set, and shouldn't be triggering anyway) but none to rsync_export_all_ro.

In the interests of getting a complete backup, how can I add this directory tree to the set of files that can be exported by the rsync daemon? (And for this change to be persistent across reboots.)

9
  • Are you interested in semanage permissive -a rsync_t ?
    – Jeff Schaller
    Aug 6, 2019 at 18:09
  • @Jeff I would have preferred to leave the actual files out of the title so as to keep the question context general Aug 6, 2019 at 18:10
  • @Jeff my usual approach is simply to switch off SELinux. This time I'm trying to "do it right". Permissive mode doesn't seem "right" to me. Is it...? Aug 6, 2019 at 18:11
  • I like to have something resembling the error or the problem in the title; I took that from the end of the post ("how can I add this directory tree"); if the problem is wider, please feel free to adjust it.
    – Jeff Schaller
    Aug 6, 2019 at 18:15
  • Thanks. More interested (this time) in understanding why the rsync_export_all_ro doesn't cover everything like it claims, and how I would go about fixing that. Aug 6, 2019 at 18:29

1 Answer 1

4

You are right to not wanting to disable SELinux for the rsync_t domain. Unfortunately, although the configurability of the SELinux implementation for rsync is fairly extensive, there are edge cases where setting the rsync_export_all_ro boolean will still not allow the rsync daemon to access certain files. There is one Bugzilla entry which closely resembles your troubles. The suggestion given there is to use rsync_full_access to overcome the problem, albeit impairing security (it is still better than semanage permissive -a rsync_t though).

Creating custom policy module

So, to answer your question, if you want to use the safer option rsync_export_all_ro and be able to let the rsync daemon access the "edge case" files/directories, you need to create your own policy module.

This is done by letting the rsync daemon do it's work in permissive mode, capturing AVC denials as it goes along, and then converting the AVC denials to a policy, like so:

# put SELinux in permissive mode
setenforce 0

# --- do your rsync stuff ---

# get related AVC denials
# I'm using 'recent' here, depending on the rsync run time please adjust accordingly
ausearch -m avc -ts recent --subject rsync_t

# go through the output. If you're satisfied, create the module
ausearch -m avc -ts recent --subject rsync_t | audit2allow -m roaima-rsync-custom-1 > roaima-rsync-custom-1.te
checkmodule -M -m -o roaima-rsync-custom-1.mod roaima-rsync-custom-1.te
semodule_package -o roaima-rsync-custom-1.pp -m roaima-rsync-custom-1.mod

# load the policy module
semodule -i roaima-rsync-custom-1.pp

# disable permissive mode
setenforce 1

# --- do your rsync stuff again --

Catching AVC denials that aren't audited ("dontaudit")

If for some reason, the "edge case" files still aren't accessible and the ausearch command doesn't yield results, you may be hitting a "dontaudit" rule.

To rebuild the SELinux policy ignoring all "dontaudit"-rules, run semodule -DB. The -D option disables "dontaudit" rules; the -B option rebuilds the policy.

Then try if you can trigger audit log events. If so, capture them like I showed above, create the SELinux module, and then re-enable "dontaudit" rules by running: semodule -B.

For a full list of "dontaudit" rules, run the sesearch --dontaudit command. Narrow down searches using the -s domain option and the grep command. For example: sesearch --dontaudit -s rsync_t.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .