Re: Backups with rsync totally broken in Fedora 18

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"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



[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux