4:20 p.m.
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.
--
View this message in context:
http://www.nabble.com/rsync-as-backup-from-f11-to-F10---issues-tp24925988...
Sent from the Fedora SELinux List mailing list archive at Nabble.com.
4:30 p.m.
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
--
View this message in context:
http://www.nabble.com/rsync-as-backup-from-f11-to-F10---issues-tp24925988...
Sent from the Fedora SELinux List mailing list archive at Nabble.com.
3:36 p.m.
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.
4:07 p.m.
On Wed, Aug 12, 2009 at 9:36 PM, Daniel J Walsh<dwalsh(a)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?
--
mike
7:52 p.m.
On 08/12/2009 05:07 PM, mike cloaked wrote:
> On Wed, Aug 12, 2009 at 9:36 PM, Daniel J
Walsh<dwalsh(a)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/
4:26 a.m.
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?
--
View this message in context:
http://www.nabble.com/rsync-as-backup-from-f11-to-F10---issues-tp24925988...
Sent from the Fedora SELinux List mailing list archive at Nabble.com.
5:38 a.m.
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.
2:41 p.m.
On Thu, Aug 13, 2009 at 11:38 AM, Paul Howarth<paul(a)city-fan.org> wrote:
You'll like this:
http://danwalsh.livejournal.com/27571.html
Paul.
Indeed - that is a useful entry....
--
mike
12:46 p.m.
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.
6:55 a.m.
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?
--
Stephen Smalley
National Security Agency
9:41 a.m.
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.
1:37 p.m.
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?
--
View this message in context:
http://www.nabble.com/rsync-as-backup-from-f11-to-F10---issues-tp24925988...
Sent from the Fedora SELinux List mailing list archive at Nabble.com.
1:39 p.m.
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?
--
View this message in context:
http://www.nabble.com/rsync-as-backup-from-f11-to-F10---issues-tp24925988...
Sent from the Fedora SELinux List mailing list archive at Nabble.com.
12:15 p.m.
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...
--
Stephen Smalley
National Security Agency
2:15 p.m.
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 ?
5365
days inactive
5371
days old
selinux@lists.fedoraproject.org
14 comments
5 participants
participants (5)
-
Daniel J Walsh -
Genes MailLists -
mike cloaked -
Paul Howarth -
Stephen Smalley