-----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.
-----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-----