"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@xxxxxxxxxxxxxxxxxxxxxxx > > > >>>>>>>>>>>>>>>>>>>> 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@xxxxxxxxxxxxxxxxxxxxxxx > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > > >>>> > > > >>>>>>>>>>>>>>>>> > > > > > > > >>>>>>>>>>>>>>>>> > > > - -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx > > > >>>>>>>>>>>>>>>> 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@xxxxxxxxxxxxxxxxxxxxxxx > > > >>>>>>>>>> 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@xxxxxxxxxxxxxxxxxxxxxxx > > https://admin.fedoraproject.org/mailman/listinfo/selinux > > > -- > selinux mailing list > selinux@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/selinux > -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
