"Daniel J Walsh wrote:"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/22/2013 03:36 PM, David Highley wrote:
"Daniel J Walsh wrote:"
On 01/22/2013 12:32 PM, David Highley wrote:
"Daniel J Walsh wrote:"
On 01/22/2013 09:39 AM, David Highley wrote:
>> "Daniel J Walsh wrote:" >>> >> On 01/21/2013 06:13 PM, David Highley wrote: >>>>> "Daniel J Walsh wrote:" >>>>>> >>>>> On 01/21/2013 12:49 PM, David Highley wrote: >>>>>>>> "Daniel J Walsh wrote:" >>>>>>>>> >>>>>>>> On 01/18/2013 09:29 PM, David Highley wrote: >>>>>>>>>>> "David Highley wrote:" >>>>>>>>>>>> >>>>>>>>>>>> "Daniel J Walsh wrote:" >>>>>>>>>>>>> >>>>>>>>>>> On 01/18/2013 09:20 AM, David Highley wrote: >>>>>>>>>>>>>>> Upgraded a test box to Fedora 18 and >>>>>>>>>>>>>>> have tried to get rsync backups to it >>>>>>>>>>>>>>> working. Looked at many discussions >>>>>>>>>>>>>>> about backing up in a selinux >>>>>>>>>>>>>>> environment and all discussions >>>>>>>>>>>>>>> seemed to be incomplete. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Most indicate you should not keep >>>>>>>>>>>>>>> selinux labels, but none of those >>>>>>>>>>>>>>> discussion indicate what options to >>>>>>>>>>>>>>> change. After working on a thousand >>>>>>>>>>>>>>> line policy file I'm beginning to >>>>>>>>>>>>>>> think you just want to completely >>>>>>>>>>>>>>> turn off any audit of the rsync >>>>>>>>>>>>>>> domain. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is this how we should approach >>>>>>>>>>>>>>> backups? If you do not preserve >>>>>>>>>>>>>>> selinux labels what should the backup >>>>>>>>>>>>>>> location get labeled to? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm surprised as long as selinux has >>>>>>>>>>>>>>> been in use that a template with >>>>>>>>>>>>>>> details has not been defined for >>>>>>>>>>>>>>> this. By the way I had just submitted >>>>>>>>>>>>>>> an enhancement bug report for rsync >>>>>>>>>>>>>>> with examples of getting it to >>>>>>>>>>>>>>> function with systemd control. -- >>>>>>>>>>>>>>> selinux mailing list >>>>>>>>>>>>>>> selinux@lists.fedoraproject.org >>>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
Does this help?
>>>>>>>>>>> >>>>>>>>>>> http://danwalsh.livejournal.com/61646.html >>>>>>>>>>>>> >>>>>>>>>>>>> I had found and read this information, >>>>>>>>>>>>> but was not sure from it and the other >>>>>>>>>>>>> discussions that it was the right >>>>>>>>>>>>> direction and if the right direction that >>>>>>>>>>>>> it had complete information for doing the >>>>>>>>>>>>> implementation. >>>>>>>>>>>>> >>>>>>>>>>>>> Has anyone tried this and has it worked >>>>>>>>>>>>> out? Do you define the backup area as >>>>>>>>>>>>> unconfined_u and relabel everything to >>>>>>>>>>>>> that? >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> OK, making rsync_t and unconfined domain >>>>>>>>>>>> gets rid of the AVCs. I still have concerns >>>>>>>>>>>> that it is just opening up a bad whole in >>>>>>>>>>>> the system. Is there a way of scoping it to >>>>>>>>>>>> only the back up area and or maybe forcing >>>>>>>>>>>> what ever is copied to a benign state by >>>>>>>>>>>> labeling it to something safe? >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> -- selinux mailing list >>>>>>>>>>>> selinux@lists.fedoraproject.org >>>>>>>>>>>> >>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
- -- selinux mailing list selinux@lists.fedoraproject.org
>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>
>>>>>>>>>>>
Well rsync_t policy if for running rsync as a daemon not as a
>>>>>>>> client. >>>>>>>> >>>>>>>> /usr/lib/systemd/system/rsyncd.service >>>>>>>> >>>>>>>> I just checked a fix into the policy so that only >>>>>>>> rsynd when run as a service will transition to >>>>>>>> rsync_t. But if you run it from a script or an >>>>>>>> application running as initrc_t, it will stay as >>>>>>>> the current domain. >>>>>>>> >>>>>>>>> Thanks, will check again when it is available. We >>>>>>>>> are using rsync as daemon spond by systemd. >>>>>>>> >>>>>>>> >>>>>>>> If you are only running rsync as a client, adding >>>>>>>> unconfined_domain(rsync_t) will not give it more >>>>>>>> privs that initrc_t already has. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> Ok then that is different, what is broken for you? >>>>> Without the unconfined_domain(rsync_t)? >>>>> >>>>> Sorry for the confusion. >>>>> >>>>>> OK, maybe the issue of confusion is what is the client >>>>>> and what is the server in the process. We have systems >>>>>> that we back up to, servers. They run rsyncd via >>>>>> systemd port activation requests. We have clients that >>>>>> run cron jobs to push back ups to one or more backup >>>>>> systems. >>>>> >>>>>> What we see with Fedora 18 selinux on the backup >>>>>> servers block everything. When I mean everything it >>>>>> seems to block almost all operations from getattr to >>>>>> relabel to unlink, name it, it is blocked. >>>>> >>>>>> This pretty much just worked for Fedora 16 and 17. >>>>> >>>>>> >>>>> -- selinux mailing list selinux@lists.fedoraproject.org >>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>> >> Could you send me a compresses audit.log? >> >>> Attached bzip2 file. >> >>>
This looks like you are having your rsync server accepts files from a remote machine and then writing them to anywhere on the local machine. Meaning you really need to have rules like:
Not really, the rsync configuration file defines where the back ups go by system all under one directory. So one of my previous questions was can we identify that area to selinux? Sould we relabel the back up area? If we define it some how then we assume a complete relabel of the storage would do the right thing.
allow rsync_t file_type:file create_file_perms;
Or a boolean like ftp_full_access
tunable_policy(`ftpd_full_access',` allow ftpd_t self:capability { dac_override dac_read_search }; files_manage_non_security_files(ftpd_t) ')
FOr rsync.
I thought the way you were supposed to use rsync was to pick a subdir where rsync would write its data to, and then label this rsync_data_t. But in your case it looks like the rsync server is trying to maintain the labels that it gets from the remote end? If it is not actually trying to overwrite local labels.
Ah, the answer I have been trying to get to. The policies expect the back up area to be labeled rsync_data_t. So the fix is not to preserve labels and to define to selinux the back up area by labeling it to rsync_data_t. That should do it. In all the researching I never found or remember seeing that the back up area should be labled rsync_data_t. Thanks
man rsync_selinux ... rsync_data_t
- Set files with the rsync_data_t type, if you want to treat the files as rsync content.
Egg on face, somehow missed that information. Now if there were a better/faster way of relabeling the back up area. Still experimenting with rsync options as the man pages give no direct reference to selinux and the internet information indicates removing the -X option but were not sure that is enough. Thanks Dan for the help and support.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlD++NUACgkQrlYvE4MpobMOYQCg5+fbjD1VU8GfIPh3rBHcf1RS gJ0AoKeT/BPPIiMwt8B2xv43+B91wg/K =xu4O -----END PGP SIGNATURE-----
"David Highley wrote:"
"Daniel J Walsh wrote:"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/22/2013 03:36 PM, David Highley wrote:
"Daniel J Walsh wrote:"
On 01/22/2013 12:32 PM, David Highley wrote:
"Daniel J Walsh wrote:" > On 01/22/2013 09:39 AM, David Highley wrote: >>> "Daniel J Walsh wrote:" >>>> >>> On 01/21/2013 06:13 PM, David Highley wrote: >>>>>> "Daniel J Walsh wrote:" >>>>>>> >>>>>> On 01/21/2013 12:49 PM, David Highley wrote: >>>>>>>>> "Daniel J Walsh wrote:" >>>>>>>>>> >>>>>>>>> On 01/18/2013 09:29 PM, David Highley wrote: >>>>>>>>>>>> "David Highley wrote:" >>>>>>>>>>>>> >>>>>>>>>>>>> "Daniel J Walsh wrote:" >>>>>>>>>>>>>> >>>>>>>>>>>> On 01/18/2013 09:20 AM, David Highley wrote: >>>>>>>>>>>>>>>> Upgraded a test box to Fedora 18 and >>>>>>>>>>>>>>>> have tried to get rsync backups to it >>>>>>>>>>>>>>>> working. Looked at many discussions >>>>>>>>>>>>>>>> about backing up in a selinux >>>>>>>>>>>>>>>> environment and all discussions >>>>>>>>>>>>>>>> seemed to be incomplete. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Most indicate you should not keep >>>>>>>>>>>>>>>> selinux labels, but none of those >>>>>>>>>>>>>>>> discussion indicate what options to >>>>>>>>>>>>>>>> change. After working on a thousand >>>>>>>>>>>>>>>> line policy file I'm beginning to >>>>>>>>>>>>>>>> think you just want to completely >>>>>>>>>>>>>>>> turn off any audit of the rsync >>>>>>>>>>>>>>>> domain. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is this how we should approach >>>>>>>>>>>>>>>> backups? If you do not preserve >>>>>>>>>>>>>>>> selinux labels what should the backup >>>>>>>>>>>>>>>> location get labeled to? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm surprised as long as selinux has >>>>>>>>>>>>>>>> been in use that a template with >>>>>>>>>>>>>>>> details has not been defined for >>>>>>>>>>>>>>>> this. By the way I had just submitted >>>>>>>>>>>>>>>> an enhancement bug report for rsync >>>>>>>>>>>>>>>> with examples of getting it to >>>>>>>>>>>>>>>> function with systemd control. -- >>>>>>>>>>>>>>>> selinux mailing list >>>>>>>>>>>>>>>> selinux@lists.fedoraproject.org >>>>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
Does this help?
>>>>>>>>>>>> >>>>>>>>>>>> http://danwalsh.livejournal.com/61646.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> I had found and read this information, >>>>>>>>>>>>>> but was not sure from it and the other >>>>>>>>>>>>>> discussions that it was the right >>>>>>>>>>>>>> direction and if the right direction that >>>>>>>>>>>>>> it had complete information for doing the >>>>>>>>>>>>>> implementation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Has anyone tried this and has it worked >>>>>>>>>>>>>> out? Do you define the backup area as >>>>>>>>>>>>>> unconfined_u and relabel everything to >>>>>>>>>>>>>> that? >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> OK, making rsync_t and unconfined domain >>>>>>>>>>>>> gets rid of the AVCs. I still have concerns >>>>>>>>>>>>> that it is just opening up a bad whole in >>>>>>>>>>>>> the system. Is there a way of scoping it to >>>>>>>>>>>>> only the back up area and or maybe forcing >>>>>>>>>>>>> what ever is copied to a benign state by >>>>>>>>>>>>> labeling it to something safe? >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> -- selinux mailing list >>>>>>>>>>>>> selinux@lists.fedoraproject.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
- -- selinux mailing list selinux@lists.fedoraproject.org
>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>
>>>>>>>>>>>>
Well rsync_t policy if for running rsync as a daemon not as a
>>>>>>>>> client. >>>>>>>>> >>>>>>>>> /usr/lib/systemd/system/rsyncd.service >>>>>>>>> >>>>>>>>> I just checked a fix into the policy so that only >>>>>>>>> rsynd when run as a service will transition to >>>>>>>>> rsync_t. But if you run it from a script or an >>>>>>>>> application running as initrc_t, it will stay as >>>>>>>>> the current domain. >>>>>>>>> >>>>>>>>>> Thanks, will check again when it is available. We >>>>>>>>>> are using rsync as daemon spond by systemd. >>>>>>>>> >>>>>>>>> >>>>>>>>> If you are only running rsync as a client, adding >>>>>>>>> unconfined_domain(rsync_t) will not give it more >>>>>>>>> privs that initrc_t already has. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> Ok then that is different, what is broken for you? >>>>>> Without the unconfined_domain(rsync_t)? >>>>>> >>>>>> Sorry for the confusion. >>>>>> >>>>>>> OK, maybe the issue of confusion is what is the client >>>>>>> and what is the server in the process. We have systems >>>>>>> that we back up to, servers. They run rsyncd via >>>>>>> systemd port activation requests. We have clients that >>>>>>> run cron jobs to push back ups to one or more backup >>>>>>> systems. >>>>>> >>>>>>> What we see with Fedora 18 selinux on the backup >>>>>>> servers block everything. When I mean everything it >>>>>>> seems to block almost all operations from getattr to >>>>>>> relabel to unlink, name it, it is blocked. >>>>>> >>>>>>> This pretty much just worked for Fedora 16 and 17. >>>>>> >>>>>>> >>>>>> -- selinux mailing list selinux@lists.fedoraproject.org >>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>> >>> Could you send me a compresses audit.log? >>> >>>> Attached bzip2 file. >>> >>>>
This looks like you are having your rsync server accepts files from a remote machine and then writing them to anywhere on the local machine. Meaning you really need to have rules like:
> Not really, the rsync configuration file defines where the back ups > go by system all under one directory. So one of my previous > questions was can we identify that area to selinux? Sould we > relabel the back up area? If we define it some how then we assume a > complete relabel of the storage would do the right thing.
allow rsync_t file_type:file create_file_perms;
Or a boolean like ftp_full_access
tunable_policy(`ftpd_full_access',` allow ftpd_t self:capability { dac_override dac_read_search }; files_manage_non_security_files(ftpd_t) ')
FOr rsync. >
I thought the way you were supposed to use rsync was to pick a subdir where rsync would write its data to, and then label this rsync_data_t. But in your case it looks like the rsync server is trying to maintain the labels that it gets from the remote end? If it is not actually trying to overwrite local labels.
Ah, the answer I have been trying to get to. The policies expect the back up area to be labeled rsync_data_t. So the fix is not to preserve labels and to define to selinux the back up area by labeling it to rsync_data_t. That should do it. In all the researching I never found or remember seeing that the back up area should be labled rsync_data_t. Thanks
man rsync_selinux ... rsync_data_t
- Set files with the rsync_data_t type, if you want to treat the files as rsync content.Egg on face, somehow missed that information. Now if there were a better/faster way of relabeling the back up area. Still experimenting with rsync options as the man pages give no direct reference to selinux and the internet information indicates removing the -X option but were not sure that is enough. Thanks Dan for the help and support.
This stuff is never easy. We now have an equivalency rule blocking the label change. What command removes the equivalency rule?
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlD++NUACgkQrlYvE4MpobMOYQCg5+fbjD1VU8GfIPh3rBHcf1RS gJ0AoKeT/BPPIiMwt8B2xv43+B91wg/K =xu4O -----END PGP SIGNATURE-----
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
"David Highley wrote:"
"David Highley wrote:"
"Daniel J Walsh wrote:"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/22/2013 03:36 PM, David Highley wrote:
"Daniel J Walsh wrote:"
On 01/22/2013 12:32 PM, David Highley wrote:
> "Daniel J Walsh wrote:" >> > On 01/22/2013 09:39 AM, David Highley wrote: >>>> "Daniel J Walsh wrote:" >>>>> >>>> On 01/21/2013 06:13 PM, David Highley wrote: >>>>>>> "Daniel J Walsh wrote:" >>>>>>>> >>>>>>> On 01/21/2013 12:49 PM, David Highley wrote: >>>>>>>>>> "Daniel J Walsh wrote:" >>>>>>>>>>> >>>>>>>>>> On 01/18/2013 09:29 PM, David Highley wrote: >>>>>>>>>>>>> "David Highley wrote:" >>>>>>>>>>>>>> >>>>>>>>>>>>>> "Daniel J Walsh wrote:" >>>>>>>>>>>>>>> >>>>>>>>>>>>> On 01/18/2013 09:20 AM, David Highley wrote: >>>>>>>>>>>>>>>>> Upgraded a test box to Fedora 18 and >>>>>>>>>>>>>>>>> have tried to get rsync backups to it >>>>>>>>>>>>>>>>> working. Looked at many discussions >>>>>>>>>>>>>>>>> about backing up in a selinux >>>>>>>>>>>>>>>>> environment and all discussions >>>>>>>>>>>>>>>>> seemed to be incomplete. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Most indicate you should not keep >>>>>>>>>>>>>>>>> selinux labels, but none of those >>>>>>>>>>>>>>>>> discussion indicate what options to >>>>>>>>>>>>>>>>> change. After working on a thousand >>>>>>>>>>>>>>>>> line policy file I'm beginning to >>>>>>>>>>>>>>>>> think you just want to completely >>>>>>>>>>>>>>>>> turn off any audit of the rsync >>>>>>>>>>>>>>>>> domain. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Is this how we should approach >>>>>>>>>>>>>>>>> backups? If you do not preserve >>>>>>>>>>>>>>>>> selinux labels what should the backup >>>>>>>>>>>>>>>>> location get labeled to? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm surprised as long as selinux has >>>>>>>>>>>>>>>>> been in use that a template with >>>>>>>>>>>>>>>>> details has not been defined for >>>>>>>>>>>>>>>>> this. By the way I had just submitted >>>>>>>>>>>>>>>>> an enhancement bug report for rsync >>>>>>>>>>>>>>>>> with examples of getting it to >>>>>>>>>>>>>>>>> function with systemd control. -- >>>>>>>>>>>>>>>>> selinux mailing list >>>>>>>>>>>>>>>>> selinux@lists.fedoraproject.org >>>>>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
Does this help?
>>>>>>>>>>>>> >>>>>>>>>>>>> http://danwalsh.livejournal.com/61646.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I had found and read this information, >>>>>>>>>>>>>>> but was not sure from it and the other >>>>>>>>>>>>>>> discussions that it was the right >>>>>>>>>>>>>>> direction and if the right direction that >>>>>>>>>>>>>>> it had complete information for doing the >>>>>>>>>>>>>>> implementation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Has anyone tried this and has it worked >>>>>>>>>>>>>>> out? Do you define the backup area as >>>>>>>>>>>>>>> unconfined_u and relabel everything to >>>>>>>>>>>>>>> that? >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> OK, making rsync_t and unconfined domain >>>>>>>>>>>>>> gets rid of the AVCs. I still have concerns >>>>>>>>>>>>>> that it is just opening up a bad whole in >>>>>>>>>>>>>> the system. Is there a way of scoping it to >>>>>>>>>>>>>> only the back up area and or maybe forcing >>>>>>>>>>>>>> what ever is copied to a benign state by >>>>>>>>>>>>>> labeling it to something safe? >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- selinux mailing list >>>>>>>>>>>>>> selinux@lists.fedoraproject.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>>
>>>>>>>>>>>>>>
- -- selinux mailing list selinux@lists.fedoraproject.org
>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>
>>>>>>>>>>>>>
Well rsync_t policy if for running rsync as a daemon not as a
>>>>>>>>>> client. >>>>>>>>>> >>>>>>>>>> /usr/lib/systemd/system/rsyncd.service >>>>>>>>>> >>>>>>>>>> I just checked a fix into the policy so that only >>>>>>>>>> rsynd when run as a service will transition to >>>>>>>>>> rsync_t. But if you run it from a script or an >>>>>>>>>> application running as initrc_t, it will stay as >>>>>>>>>> the current domain. >>>>>>>>>> >>>>>>>>>>> Thanks, will check again when it is available. We >>>>>>>>>>> are using rsync as daemon spond by systemd. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If you are only running rsync as a client, adding >>>>>>>>>> unconfined_domain(rsync_t) will not give it more >>>>>>>>>> privs that initrc_t already has. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> Ok then that is different, what is broken for you? >>>>>>> Without the unconfined_domain(rsync_t)? >>>>>>> >>>>>>> Sorry for the confusion. >>>>>>> >>>>>>>> OK, maybe the issue of confusion is what is the client >>>>>>>> and what is the server in the process. We have systems >>>>>>>> that we back up to, servers. They run rsyncd via >>>>>>>> systemd port activation requests. We have clients that >>>>>>>> run cron jobs to push back ups to one or more backup >>>>>>>> systems. >>>>>>> >>>>>>>> What we see with Fedora 18 selinux on the backup >>>>>>>> servers block everything. When I mean everything it >>>>>>>> seems to block almost all operations from getattr to >>>>>>>> relabel to unlink, name it, it is blocked. >>>>>>> >>>>>>>> This pretty much just worked for Fedora 16 and 17. >>>>>>> >>>>>>>> >>>>>>> -- selinux mailing list selinux@lists.fedoraproject.org >>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>> >>>> Could you send me a compresses audit.log? >>>> >>>>> Attached bzip2 file. >>>> >>>>> > > This looks like you are having your rsync server accepts files from > a remote machine and then writing them to anywhere on the local > machine. Meaning you really need to have rules like: > >> Not really, the rsync configuration file defines where the back ups >> go by system all under one directory. So one of my previous >> questions was can we identify that area to selinux? Sould we >> relabel the back up area? If we define it some how then we assume a >> complete relabel of the storage would do the right thing. > > > > allow rsync_t file_type:file create_file_perms; > > Or a boolean like ftp_full_access > > tunable_policy(`ftpd_full_access',` allow ftpd_t self:capability { > dac_override dac_read_search }; > files_manage_non_security_files(ftpd_t) ') > > FOr rsync. >>
I thought the way you were supposed to use rsync was to pick a subdir where rsync would write its data to, and then label this rsync_data_t. But in your case it looks like the rsync server is trying to maintain the labels that it gets from the remote end? If it is not actually trying to overwrite local labels.
Ah, the answer I have been trying to get to. The policies expect the back up area to be labeled rsync_data_t. So the fix is not to preserve labels and to define to selinux the back up area by labeling it to rsync_data_t. That should do it. In all the researching I never found or remember seeing that the back up area should be labled rsync_data_t. Thanks
man rsync_selinux ... rsync_data_t
- Set files with the rsync_data_t type, if you want to treat the files as rsync content.Egg on face, somehow missed that information. Now if there were a better/faster way of relabeling the back up area. Still experimenting with rsync options as the man pages give no direct reference to selinux and the internet information indicates removing the -X option but were not sure that is enough. Thanks Dan for the help and support.
This stuff is never easy. We now have an equivalency rule blocking the label change. What command removes the equivalency rule?
"Flat forhead, bald head"; the engineering methodology found solution. semanage fcontext -d </path>
At least the label change stopped squawking.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlD++NUACgkQrlYvE4MpobMOYQCg5+fbjD1VU8GfIPh3rBHcf1RS gJ0AoKeT/BPPIiMwt8B2xv43+B91wg/K =xu4O -----END PGP SIGNATURE-----
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
"David Highley wrote:"
"David Highley wrote:"
"David Highley wrote:"
"Daniel J Walsh wrote:"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/22/2013 03:36 PM, David Highley wrote:
"Daniel J Walsh wrote:"
On 01/22/2013 12:32 PM, David Highley wrote:
>> "Daniel J Walsh wrote:" >>> >> On 01/22/2013 09:39 AM, David Highley wrote: >>>>> "Daniel J Walsh wrote:" >>>>>> >>>>> On 01/21/2013 06:13 PM, David Highley wrote: >>>>>>>> "Daniel J Walsh wrote:" >>>>>>>>> >>>>>>>> On 01/21/2013 12:49 PM, David Highley wrote: >>>>>>>>>>> "Daniel J Walsh wrote:" >>>>>>>>>>>> >>>>>>>>>>> On 01/18/2013 09:29 PM, David Highley wrote: >>>>>>>>>>>>>> "David Highley wrote:" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "Daniel J Walsh wrote:" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> On 01/18/2013 09:20 AM, David Highley wrote: >>>>>>>>>>>>>>>>>> Upgraded a test box to Fedora 18 and >>>>>>>>>>>>>>>>>> have tried to get rsync backups to it >>>>>>>>>>>>>>>>>> working. Looked at many discussions >>>>>>>>>>>>>>>>>> about backing up in a selinux >>>>>>>>>>>>>>>>>> environment and all discussions >>>>>>>>>>>>>>>>>> seemed to be incomplete. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Most indicate you should not keep >>>>>>>>>>>>>>>>>> selinux labels, but none of those >>>>>>>>>>>>>>>>>> discussion indicate what options to >>>>>>>>>>>>>>>>>> change. After working on a thousand >>>>>>>>>>>>>>>>>> line policy file I'm beginning to >>>>>>>>>>>>>>>>>> think you just want to completely >>>>>>>>>>>>>>>>>> turn off any audit of the rsync >>>>>>>>>>>>>>>>>> domain. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Is this how we should approach >>>>>>>>>>>>>>>>>> backups? If you do not preserve >>>>>>>>>>>>>>>>>> selinux labels what should the backup >>>>>>>>>>>>>>>>>> location get labeled to? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'm surprised as long as selinux has >>>>>>>>>>>>>>>>>> been in use that a template with >>>>>>>>>>>>>>>>>> details has not been defined for >>>>>>>>>>>>>>>>>> this. By the way I had just submitted >>>>>>>>>>>>>>>>>> an enhancement bug report for rsync >>>>>>>>>>>>>>>>>> with examples of getting it to >>>>>>>>>>>>>>>>>> function with systemd control. -- >>>>>>>>>>>>>>>>>> selinux mailing list >>>>>>>>>>>>>>>>>> selinux@lists.fedoraproject.org >>>>>>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
Does this help?
>>>>>>>>>>>>>> >>>>>>>>>>>>>> http://danwalsh.livejournal.com/61646.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I had found and read this information, >>>>>>>>>>>>>>>> but was not sure from it and the other >>>>>>>>>>>>>>>> discussions that it was the right >>>>>>>>>>>>>>>> direction and if the right direction that >>>>>>>>>>>>>>>> it had complete information for doing the >>>>>>>>>>>>>>>> implementation. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Has anyone tried this and has it worked >>>>>>>>>>>>>>>> out? Do you define the backup area as >>>>>>>>>>>>>>>> unconfined_u and relabel everything to >>>>>>>>>>>>>>>> that? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> OK, making rsync_t and unconfined domain >>>>>>>>>>>>>>> gets rid of the AVCs. I still have concerns >>>>>>>>>>>>>>> that it is just opening up a bad whole in >>>>>>>>>>>>>>> the system. Is there a way of scoping it to >>>>>>>>>>>>>>> only the back up area and or maybe forcing >>>>>>>>>>>>>>> what ever is copied to a benign state by >>>>>>>>>>>>>>> labeling it to something safe? >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- selinux mailing list >>>>>>>>>>>>>>> selinux@lists.fedoraproject.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
- -- selinux mailing list selinux@lists.fedoraproject.org
>>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>
>>>>>>>>>>>>>>
Well rsync_t policy if for running rsync as a daemon not as a
>>>>>>>>>>> client. >>>>>>>>>>> >>>>>>>>>>> /usr/lib/systemd/system/rsyncd.service >>>>>>>>>>> >>>>>>>>>>> I just checked a fix into the policy so that only >>>>>>>>>>> rsynd when run as a service will transition to >>>>>>>>>>> rsync_t. But if you run it from a script or an >>>>>>>>>>> application running as initrc_t, it will stay as >>>>>>>>>>> the current domain. >>>>>>>>>>> >>>>>>>>>>>> Thanks, will check again when it is available. We >>>>>>>>>>>> are using rsync as daemon spond by systemd. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If you are only running rsync as a client, adding >>>>>>>>>>> unconfined_domain(rsync_t) will not give it more >>>>>>>>>>> privs that initrc_t already has. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>> Ok then that is different, what is broken for you? >>>>>>>> Without the unconfined_domain(rsync_t)? >>>>>>>> >>>>>>>> Sorry for the confusion. >>>>>>>> >>>>>>>>> OK, maybe the issue of confusion is what is the client >>>>>>>>> and what is the server in the process. We have systems >>>>>>>>> that we back up to, servers. They run rsyncd via >>>>>>>>> systemd port activation requests. We have clients that >>>>>>>>> run cron jobs to push back ups to one or more backup >>>>>>>>> systems. >>>>>>>> >>>>>>>>> What we see with Fedora 18 selinux on the backup >>>>>>>>> servers block everything. When I mean everything it >>>>>>>>> seems to block almost all operations from getattr to >>>>>>>>> relabel to unlink, name it, it is blocked. >>>>>>>> >>>>>>>>> This pretty much just worked for Fedora 16 and 17. >>>>>>>> >>>>>>>>> >>>>>>>> -- selinux mailing list selinux@lists.fedoraproject.org >>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>> >>>>> Could you send me a compresses audit.log? >>>>> >>>>>> Attached bzip2 file. >>>>> >>>>>> >> >> This looks like you are having your rsync server accepts files from >> a remote machine and then writing them to anywhere on the local >> machine. Meaning you really need to have rules like: >> >>> Not really, the rsync configuration file defines where the back ups >>> go by system all under one directory. So one of my previous >>> questions was can we identify that area to selinux? Sould we >>> relabel the back up area? If we define it some how then we assume a >>> complete relabel of the storage would do the right thing. >> >> >> >> allow rsync_t file_type:file create_file_perms; >> >> Or a boolean like ftp_full_access >> >> tunable_policy(`ftpd_full_access',` allow ftpd_t self:capability { >> dac_override dac_read_search }; >> files_manage_non_security_files(ftpd_t) ') >> >> FOr rsync. >>>
I thought the way you were supposed to use rsync was to pick a subdir where rsync would write its data to, and then label this rsync_data_t. But in your case it looks like the rsync server is trying to maintain the labels that it gets from the remote end? If it is not actually trying to overwrite local labels.
Ah, the answer I have been trying to get to. The policies expect the back up area to be labeled rsync_data_t. So the fix is not to preserve labels and to define to selinux the back up area by labeling it to rsync_data_t. That should do it. In all the researching I never found or remember seeing that the back up area should be labled rsync_data_t. Thanks
man rsync_selinux ... rsync_data_t
- Set files with the rsync_data_t type, if you want to treat the files as rsync content.Egg on face, somehow missed that information. Now if there were a better/faster way of relabeling the back up area. Still experimenting with rsync options as the man pages give no direct reference to selinux and the internet information indicates removing the -X option but were not sure that is enough. Thanks Dan for the help and support.
This stuff is never easy. We now have an equivalency rule blocking the label change. What command removes the equivalency rule?
"Flat forhead, bald head"; the engineering methodology found solution. semanage fcontext -d </path>
At least the label change stopped squawking.
Still no joy. As soon as we remove the unconfined policy for rsync the AVCs start flooding in. Captured another log file if you want to look at it Dan. Also removed the -A option from rsync which made no difference.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlD++NUACgkQrlYvE4MpobMOYQCg5+fbjD1VU8GfIPh3rBHcf1RS gJ0AoKeT/BPPIiMwt8B2xv43+B91wg/K =xu4O -----END PGP SIGNATURE-----
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Wed, Jan 23, 2013 at 07:20:18PM -0800, David Highley wrote:
Still no joy. As soon as we remove the unconfined policy for rsync the AVCs start flooding in. Captured another log file if you want to look at it Dan. Also removed the -A option from rsync which made no difference.
Can everyone please remember to trim their replies to the bare minimum quoted text necessary to understand the context?
Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David what AVC's are you seeing now? What commands did you set?
Something like this?
# semanage fcontext -a -t -t rsync_data_t /var/lib/backup(/.*)? # restorecon -R -v /var/lib/backup
To summarize what the solution was for doing rsync back ups on Fedora 18 where we have clients initiating rsync back ups via cron jobs to back up servers where rsync is run by connection requests via systemd control.
- Stopped preserving selinux attributes by removing the -X option from the rsync command. - Relabel the back up storage are by doing an semanage fcontext -a -t rsync_data_t </path>'(/.*)?' - On the back up servers; setsebool -P rsync_client on
We still ended up needing the following policy: policy_module(my_rsync, 1.0) require { type rsync_data_t; type rsync_t; class sock_file getattr; class capability net_admin; }
#============= rsync_t ============== allow rsync_t rsync_data_t:sock_file getattr; allow rsync_t self:capability net_admin;
Dan Walsh believes the last rule maybe a kernel bug which showed up today on Fedora 16 with kernel version 3.6.11-4 update. If you want to be able to query the back up server by doing an rsync <host>:: we need this rule for sshd: allow sshd_t rsync_data_t:file read;
Should we submit any bug reports from this effort? If so, which subsystems should they be submitted against. Dan thank you for all the support effort to resolve these issues.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/29/2013 10:57 PM, David Highley wrote:
To summarize what the solution was for doing rsync back ups on Fedora 18 where we have clients initiating rsync back ups via cron jobs to back up servers where rsync is run by connection requests via systemd control.
- Stopped preserving selinux attributes by removing the -X option from the
rsync command. - Relabel the back up storage are by doing an semanage fcontext -a -t rsync_data_t </path>'(/.*)?' - On the back up servers; setsebool -P rsync_client on
We still ended up needing the following policy: policy_module(my_rsync, 1.0) require { type rsync_data_t; type rsync_t; class sock_file getattr; class capability net_admin; }
#============= rsync_t ============== allow rsync_t rsync_data_t:sock_file getattr; allow rsync_t self:capability net_admin;
Dan Walsh believes the last rule maybe a kernel bug which showed up today on Fedora 16 with kernel version 3.6.11-4 update. If you want to be able to query the back up server by doing an rsync <host>:: we need this rule for sshd: allow sshd_t rsync_data_t:file read;
Should we submit any bug reports from this effort? If so, which subsystems should they be submitted against. Dan thank you for all the support effort to resolve these issues. -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Yes open a bug report on selinux-policy, and we will follow up on it there.
selinux@lists.fedoraproject.org
-
Chuck Anderson -
Daniel J Walsh -
David Highley