I have been running backups using rsync from various machines on my LAN onto a main (F10) machine into which is plugged a usb external drive that takes the backup files.
This year the machine into which the backup drive is plugged has been running F10 fully up to date, and with SELinux fully enforcing.
Machines on the LAN have been running backups across the network using an rsync command within a script which essentially does: rsync --delete -aXH --exclude blah /opt home1:/media/usbdrive/BACKUPS/myhostname and similar for other directories.
This has worked fine until I installed F11 on some of the machines in the LAN, with ext4 filesystems on them.
Trying the same thing in this case gave AVC denials on the machine (running F10) to which the the external usb drive was attached (and with an ext3 filesystem to take the backups)
The AVC contained: Summary SELinux is preventing rsync (unconfined_t) "mac_admin" unconfined_t. Detailed Description SELinux denied access requested by rsync. It is not expected that this access is required by rsync and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access You can generate a local policy module to allow this access - see FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. Additional Information Source Context: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Target Context: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Target Objects: None [ capability2 ] Source: rsync Source Path: /usr/bin/rsync Port: <Unknown> Host: home1.xxxxxxxxx Source RPM Packages: rsync-3.0.6-0.fc10 Target RPM Packages: Policy RPM: selinux-policy-3.5.13-67.fc10Selinux Enabled: TruePolicy Type: targeted MLS Enabled: True Enforcing Mode: Enforcing Plugin Name: catchall Host Name: home1.xxxxxxxxx Platform: Linux home1.xxxxxxxxxx 2.6.27.29-170.2.78.fc10.i686 #1 SMP Fri Jul 31 04:40:15 EDT 2009 i686 i686 Alert Count: 72 First Seen: Tue 11 Aug 2009 08:45:24 PM BST Last Seen: Tue 11 Aug 2009 08:57:08 PM BST Local ID: 2f39a50c-7f62-4e03-aa28-5826d349f52a Line Numbers: Raw Audit Messages :
node=home1.xxxxxxxxxxxxxx type=AVC msg=audit(1250020628.16:1141): avc: denied { mac_admin } for pid=18683 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
node=home1.xxxxxxxxxxxxxx type=SYSCALL msg=audit(1250020628.16:1141): arch=40000003 syscall=227 success=no exit=-22 a0=bfc81358 a1=9e3808c a2=9e38068 a3=24 items=0 ppid=18663 pid=18683 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=145 comm="rsync" exe="/usr/bin/rsync" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
This seems to stem from a context incompatibility between F10 and F11.
My work-around is as follows:
I have made a new ext4 filesystem on the external drive using mke2fs -t ext4 and labelling it using e2label, and then running the backup with the drive attached to a machine running F11 with SElinux enforcing and which has an ext4 filesystem for / and /opt.
Now I am currently running a backup from one of the other machines on the LAN which is also running F11 with SElinux enforcing and so far I am not seeing AVC denials.
My question is whether there is a workaround for the original scenario backup up files from the F11 machines onto an external drive with ext3 connected to an F10 machine with ext3 filesystem. Or is the filesystem a red herring and the problem stemming from selinux alone?
You may ask why I need to copy the extended attributes - it surely makes life easier if I restore files later.
Mike Cloaked wrote:
Machines on the LAN have been running backups across the network using an rsync command within a script which essentially does: rsync --delete -aXH --exclude blah /opt home1:/media/usbdrive/BACKUPS/myhostname and similar for other directories.
This has worked fine until I installed F11 on some of the machines in the LAN, with ext4 filesystems on them.
Trying the same thing in this case gave AVC denials on the machine (running F10) to which the the external usb drive was attached (and with an ext3 filesystem to take the backups)
The AVC contained: Summary SELinux is preventing rsync (unconfined_t) "mac_admin" unconfined_t.
I wonder if this is related to https://bugzilla.redhat.com/show_bug.cgi?id=510649
On 08/11/2009 05:30 PM, Mike Cloaked wrote:
Mike Cloaked wrote:
Machines on the LAN have been running backups across the network using an rsync command within a script which essentially does: rsync --delete -aXH --exclude blah /opt home1:/media/usbdrive/BACKUPS/myhostname and similar for other directories.
This has worked fine until I installed F11 on some of the machines in the LAN, with ext4 filesystems on them.
Trying the same thing in this case gave AVC denials on the machine (running F10) to which the the external usb drive was attached (and with an ext3 filesystem to take the backups)
The AVC contained: Summary SELinux is preventing rsync (unconfined_t) "mac_admin" unconfined_t.
I wonder if this is related to https://bugzilla.redhat.com/show_bug.cgi?id=510649
Yes you are trying to put F11 labels on an F10 box. Just setup rsync to not maintain labels.
On Wed, Aug 12, 2009 at 9:36 PM, Daniel J Walshdwalsh@redhat.com wrote:
On 08/11/2009 05:30 PM, Mike Cloaked wrote:
Mike Cloaked wrote:
Machines on the LAN have been running backups across the network using an rsync command within a script which essentially does: rsync --delete -aXH --exclude blah /opt home1:/media/usbdrive/BACKUPS/myhostname and similar for other directories.
This has worked fine until I installed F11 on some of the machines in the LAN, with ext4 filesystems on them.
Trying the same thing in this case gave AVC denials on the machine (running F10) to which the the external usb drive was attached (and with an ext3 filesystem to take the backups)
The AVC contained: Summary SELinux is preventing rsync (unconfined_t) "mac_admin" unconfined_t.
I wonder if this is related to https://bugzilla.redhat.com/show_bug.cgi?id=510649
Yes you are trying to put F11 labels on an F10 box. Just setup rsync to not maintain labels.
You mean use flags -aH and not -AXH ? I suppose that not putting labels onto the backup will then mean that restoring (if it became necessary) from the backup stored on the F10 box would then generate labels on the F11 box being restored that are correct according to current policy for F11 if I use rsync -aH during the restore process. Presumably labels of some kind will be generated on the backup drive on the F10 machine but would not be related to the labels on the originals.
Is this how others do backups?
How would this differ if rdiff-backup was used instead? Since rdiff-backup is rsync based presumably the same thinking applies?
On 08/12/2009 05:07 PM, mike cloaked wrote:
On Wed, Aug 12, 2009 at 9:36 PM, Daniel J Walshdwalsh@redhat.com
wrote: originals.
Is this how others do backups?
Cant speak for others but I do not backup selinux labels. I cannot speak to other attributes or ACL's.
I think of selinux labels as belonging to the host server policy not the backup machine - so the policy in my mind comes from the target where the backups would be restored to.
So, if you backed up /home/cloaked/foo and restored it to bing:/home/cloaked/foo then I would expect the labels to come from the policy on bing - whether or not the backup was made from bing or somewhere else.
How would this differ if rdiff-backup was used instead? Since rdiff-backup is rsync based ....
Dunno - I kind of thought rdiff-backup had better extended attribute handling than rsync itself and its my preferred tool anyway.
gene/
Mail Lists-3 wrote:
Cant speak for others but I do not backup selinux labels. I cannot speak to other attributes or ACL's.
I think of selinux labels as belonging to the host server policy not the backup machine - so the policy in my mind comes from the target where the backups would be restored to.
So, if you backed up /home/cloaked/foo and restored it to bing:/home/cloaked/foo then I would expect the labels to come from the policy on bing - whether or not the backup was made from bing or somewhere else.
How would this differ if rdiff-backup was used instead? Since rdiff-backup is rsync based ....
Dunno - I kind of thought rdiff-backup had better extended attribute handling than rsync itself and its my preferred tool anyway.
gene/
Generally true - but one situation I found the backup done my way that I liked, to include labels, was when transitioning from F10 to F11 where I had specific labels on some files in /opt to avoid avc denials in F10.
In order to move to F11 with ext4 what I did was to create a backup on the external drive and included the original labelling for F10, for the entire /opt structure. Then when I installed F11, I allowed the installer to format both / and /opt with ext4. Then once the install was completed I restored the /opt backup to the new /opt partition for F11 including the old F10 labels, and was able to progress using the files with their old contexts apart from an occasional need to change a context.
Presumably had I restored using rsync -aH only then the file contexts would have been made according to the F11 current policy and not been a generic "file_t". Some instances would certainly not have worked such as a mail spool area on /opt that would not have been given their correct mail related contexts after the restore - although I don't know if the mail spool area, once bind mounted onto the root directory mail spool, would then get their correct contexts if I used a restorecon command on the mail spool at that time?
I don't know if the same also would then apply to user areas residing on the /opt/Local/home directory? Again initially the files would have incorrect contexts restoring using rsync -aH and again once bind mounted to /home would restorecon put the correct labels back?
On 13/08/09 10:26, Mike Cloaked wrote:
Mail Lists-3 wrote:
Cant speak for others but I do not backup selinux labels. I cannot
speak to other attributes or ACL's.
I think of selinux labels as belonging to the host server policy not the backup machine - so the policy in my mind comes from the target where the backups would be restored to.
So, if you backed up /home/cloaked/foo and restored it to bing:/home/cloaked/foo then I would expect the labels to come from the policy on bing - whether or not the backup was made from bing or somewhere else.
How would this differ if rdiff-backup was used instead? Since rdiff-backup is rsync based ....
Dunno - I kind of thought rdiff-backup had better extended attribute handling than rsync itself and its my preferred tool anyway.
gene/
Generally true - but one situation I found the backup done my way that I liked, to include labels, was when transitioning from F10 to F11 where I had specific labels on some files in /opt to avoid avc denials in F10.
In order to move to F11 with ext4 what I did was to create a backup on the external drive and included the original labelling for F10, for the entire /opt structure. Then when I installed F11, I allowed the installer to format both / and /opt with ext4. Then once the install was completed I restored the /opt backup to the new /opt partition for F11 including the old F10 labels, and was able to progress using the files with their old contexts apart from an occasional need to change a context.
Presumably had I restored using rsync -aH only then the file contexts would have been made according to the F11 current policy and not been a generic "file_t". Some instances would certainly not have worked such as a mail spool area on /opt that would not have been given their correct mail related contexts after the restore - although I don't know if the mail spool area, once bind mounted onto the root directory mail spool, would then get their correct contexts if I used a restorecon command on the mail spool at that time?
I don't know if the same also would then apply to user areas residing on the /opt/Local/home directory? Again initially the files would have incorrect contexts restoring using rsync -aH and again once bind mounted to /home would restorecon put the correct labels back?
You'll like this: http://danwalsh.livejournal.com/27571.html
Paul.
On Thu, Aug 13, 2009 at 11:38 AM, Paul Howarthpaul@city-fan.org wrote:
You'll like this: http://danwalsh.livejournal.com/27571.html
Paul.
Indeed - that is a useful entry....
On 08/13/2009 05:26 AM, Mike Cloaked wrote:
Mail Lists-3 wrote:
Cant speak for others but I do not backup selinux labels. I cannot speak to other attributes or ACL's.
I think of selinux labels as belonging to the host server policy not the backup machine - so the policy in my mind comes from the target where the backups would be restored to.
So, if you backed up /home/cloaked/foo and restored it to bing:/home/cloaked/foo then I would expect the labels to come from the policy on bing - whether or not the backup was made from bing or somewhere else.
How would this differ if rdiff-backup was used instead? Since rdiff-backup is rsync based ....
Dunno - I kind of thought rdiff-backup had better extended attribute handling than rsync itself and its my preferred tool anyway.
gene/
Generally true - but one situation I found the backup done my way that I liked, to include labels, was when transitioning from F10 to F11 where I had specific labels on some files in /opt to avoid avc denials in F10.
In order to move to F11 with ext4 what I did was to create a backup on the external drive and included the original labelling for F10, for the entire /opt structure. Then when I installed F11, I allowed the installer to format both / and /opt with ext4. Then once the install was completed I restored the /opt backup to the new /opt partition for F11 including the old F10 labels, and was able to progress using the files with their old contexts apart from an occasional need to change a context.
Presumably had I restored using rsync -aH only then the file contexts would have been made according to the F11 current policy and not been a generic "file_t". Some instances would certainly not have worked such as a mail spool area on /opt that would not have been given their correct mail related contexts after the restore - although I don't know if the mail spool area, once bind mounted onto the root directory mail spool, would then get their correct contexts if I used a restorecon command on the mail spool at that time?
I don't know if the same also would then apply to user areas residing on the /opt/Local/home directory? Again initially the files would have incorrect contexts restoring using rsync -aH and again once bind mounted to /home would restorecon put the correct labels back?
I am not a sysadm, but I think it is better to backup the the files with saving the labeling, then running restorecon after you restore the labels.
If you want to change the labels some where on a system you should tell SELinux about this using the semanage fcontext -a command.
Then restorecon will fix the labels.
The problem with moving labels from one machine to another, is that you may not have the same security labels available on both machines as you have seen. If you had both machines running the same policy, it would have worked.
On Wed, 2009-08-12 at 16:36 -0400, Daniel J Walsh wrote:
On 08/11/2009 05:30 PM, Mike Cloaked wrote:
Mike Cloaked wrote:
Machines on the LAN have been running backups across the network using an rsync command within a script which essentially does: rsync --delete -aXH --exclude blah /opt home1:/media/usbdrive/BACKUPS/myhostname and similar for other directories.
This has worked fine until I installed F11 on some of the machines in the LAN, with ext4 filesystems on them.
Trying the same thing in this case gave AVC denials on the machine (running F10) to which the the external usb drive was attached (and with an ext3 filesystem to take the backups)
The AVC contained: Summary SELinux is preventing rsync (unconfined_t) "mac_admin" unconfined_t.
I wonder if this is related to https://bugzilla.redhat.com/show_bug.cgi?id=510649
Yes you are trying to put F11 labels on an F10 box. Just setup rsync to not maintain labels.
Isn't this scenario one of the reasons why we introduced the deferred context mapping support? If he allowed rsync mac_admin permission, it could in fact store the unknown labels on disk on the F10 box and later read them for restoring to the F11 system, right?
On 08/14/2009 07:55 AM, Stephen Smalley wrote:
On Wed, 2009-08-12 at 16:36 -0400, Daniel J Walsh wrote:
On 08/11/2009 05:30 PM, Mike Cloaked wrote:
Mike Cloaked wrote:
Machines on the LAN have been running backups across the network using an rsync command within a script which essentially does: rsync --delete -aXH --exclude blah /opt home1:/media/usbdrive/BACKUPS/myhostname and similar for other directories.
This has worked fine until I installed F11 on some of the machines in the LAN, with ext4 filesystems on them.
Trying the same thing in this case gave AVC denials on the machine (running F10) to which the the external usb drive was attached (and with an ext3 filesystem to take the backups)
The AVC contained: Summary SELinux is preventing rsync (unconfined_t) "mac_admin" unconfined_t.
I wonder if this is related to https://bugzilla.redhat.com/show_bug.cgi?id=510649
Yes you are trying to put F11 labels on an F10 box. Just setup rsync to not maintain labels.
Isn't this scenario one of the reasons why we introduced the deferred context mapping support? If he allowed rsync mac_admin permission, it could in fact store the unknown labels on disk on the F10 box and later read them for restoring to the F11 system, right?
Yes that would work, but I thought we were frowning on this. The files would also be unusable by any confined processes on the F10 machine, I am not sure what would happen with the association denied, errors.
Daniel J Walsh wrote:
On 08/14/2009 07:55 AM, Stephen Smalley wrote:
On Wed, 2009-08-12 at 16:36 -0400, Daniel J Walsh wrote:
On 08/11/2009 05:30 PM, Mike Cloaked wrote:
Mike Cloaked wrote:
Machines on the LAN have been running backups across the network using an rsync command within a script which essentially does: rsync --delete -aXH --exclude blah /opt home1:/media/usbdrive/BACKUPS/myhostname and similar for other directories.
This has worked fine until I installed F11 on some of the machines in the LAN, with ext4 filesystems on them.
Trying the same thing in this case gave AVC denials on the machine (running F10) to which the the external usb drive was attached (and with an ext3 filesystem to take the backups)
The AVC contained: Summary SELinux is preventing rsync (unconfined_t) "mac_admin" unconfined_t.
I wonder if this is related to https://bugzilla.redhat.com/show_bug.cgi?id=510649
Yes you are trying to put F11 labels on an F10 box. Just setup rsync to not maintain labels.
Isn't this scenario one of the reasons why we introduced the deferred context mapping support? If he allowed rsync mac_admin permission, it could in fact store the unknown labels on disk on the F10 box and later read them for restoring to the F11 system, right?
Yes that would work, but I thought we were frowning on this. The files would also be unusable by any confined processes on the F10 machine, I am not sure what would happen with the association denied, errors.
I can't speak for others but in my case once the files were stored on the disk as backups via the F10 machine they would never be used on the F10 machine, as that machine would only ever act as a conduit for backup and restore to the F11 machine - hence the files would only be used on F11 anyway - so the F10 machine is only a processing facility to get the files onto the backup drive.
Presumably the facility referred to in the link several posts back up this thread would allow this to happen?
Mike Cloaked wrote:
I can't speak for others but in my case once the files were stored on the disk as backups via the F10 machine they would never be used on the F10 machine, as that machine would only ever act as a conduit for backup and restore to the F11 machine - hence the files would only be used on F11 anyway - so the F10 machine is only a processing facility to get the files onto the backup drive.
Presumably the facility referred to in the link several posts back up this thread would allow this to happen?
Sorry - not the link but the reference to the allowing mac_admin permission... on the F10 machine?
On Sat, 2009-08-15 at 11:39 -0700, Mike Cloaked wrote:
Mike Cloaked wrote:
I can't speak for others but in my case once the files were stored on the disk as backups via the F10 machine they would never be used on the F10 machine, as that machine would only ever act as a conduit for backup and restore to the F11 machine - hence the files would only be used on F11 anyway - so the F10 machine is only a processing facility to get the files onto the backup drive.
Presumably the facility referred to in the link several posts back up this thread would allow this to happen?
Sorry - not the link but the reference to the allowing mac_admin permission... on the F10 machine?
Yes. Which you could do via a local policy module. As long as nothing confined on the F10 box needs to access those files...
On 08/15/2009 02:37 PM, Mike Cloaked wrote:
I can't speak for others but in my case once the files were stored on the disk as backups via the F10 machine they would never be used on the F10 machine, as that machine would only ever act as a conduit for backup and
I find it very convenient to be able to browse the backup tree on the server (or elsewhere if its epxorted) - thats one of the greatest benefits of using rdiff-backup or rsync no ?
selinux@lists.fedoraproject.org