"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(a)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(a)lists.fedoraproject.org
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/selinux
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>
> > >>>>>>>>>>>>>>>>>
> > >
> > >>>>>>>>>>>>>>>>>
> > - -- selinux mailing list selinux(a)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(a)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(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/selinux
>
--
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux