On 7/21/2015 5:32 AM, Miroslav Grepl wrote:
On 07/14/2015 11:56 PM, Jeff Boyce wrote:
On 7/14/2015 2:33 PM, Simon Sekidde wrote:
----- Original Message -----
From: "Stephen Smalley" <sds@xxxxxxxxxxxxx>
To: "Jeff Boyce" <jboyce@xxxxxxxxxxxxxxx>, "SELinux Fedora List"
<selinux@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, July 14, 2015 1:41:22 PM
Subject: Re: How to (or should I?) change unconfined_u to system_u
for a file
On 07/14/2015 01:04 PM, Jeff Boyce wrote:
Greetings -
I essentially have two questions here. First, I have a file that
needs the context changed and I don't have a clear understanding of the
proper syntax that should be used. Second, after doing some additional
reading through the SELinux manual and some Google searching, I
realized
that I may be taking the wrong approach with this file. Then I ran
across Dan Walsh's blog dated April 23, 2013 (Subject: What is the
differences between user_home_dir_t and user_home_t) and realize that I
am likely not doing something the appropriate way. So I am looking for
someone to educate me on my error, the risks involved, and the proper
approach I should be using.
The issue: I have two shell files run by cron that rsync our file
server directories to two backup servers, one on-site (Bison) and one
off-site. The on-site cron has worked fine for years. I just setup
the
off-site cron and it is blocked by SELinux. Looking at the context of
the files, the one that works is listed as system_u, while the one that
fails is listed as unconfined_u. So my first question is, what is the
proper syntax for changing the context of the second file so that it
matches the first one.
[root@sequoia home]# pwd
/home
[root@sequoia home]# ls -lZ | grep RsyncS
-rwxr--r--. root root system_u:object_r:home_root_t:s0
RsyncSequoiaToBison.sh
-rwxr--r--. root root unconfined_u:object_r:home_root_t:s0
RsyncSequoiaToOffsite.sh
chcon --reference=RsyncSequoiaToBison.sh RsyncSequoiaToOffsite.sh
Looking from a wider perspective, I have these shell files located in
/home. I am speculating now that for my objective, this might not be
the appropriate location for them, and is probably why SELinux is
blocking the new one I created for the off-site backup. So my second
question is more philosophical regarding what should be the location
for
a shell file that is used by cron to rsync our files to a backup
server.
What AVCs do you show for the new file?
Thanks, and please cc me directly as I only receive the daily
digest
from the mailing list.
Jeff
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
Here is the raw AVC for the denial on the new file. Maybe my initial
interpretation is wrong. I am open to being educated.
Raw Audit Messages
type=AVC msg=audit(1436888672.587:632188): avc: denied { execute }
for pid=3240 comm="rsync" name="ssh" dev=vda2 ino=159011
scontext=system_u:system_r:rsync_t:s0
tcontext=system_u:object_r:ssh_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1436888672.587:632188): arch=x86_64
syscall=execve success=no exit=EACCES a0=7fff9ec4332f a1=7fff9ec43460
a2=7fff9ec46620 a3=7f6741bba9d0 items=0 ppid=3239 pid=3240
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm=rsync exe=/usr/bin/rsync
subj=system_u:system_r:rsync_t:s0 key=(null)
#============= rsync_t ==============
#!!!! This avc can be allowed using the boolean 'rsync_client'
allow rsync_t ssh_exec_t:file execute;
Regarding Stephens response earlier, I was not familiar with the
--reference= option for chcon, but since chcon does not survive a
relabel, I am looking for a persistent change (and was expecting
something for semanage fcontext). The last thing I need it to have this
re-occur months later, with no connection back to this event.
I don't think you have still the issue with RsyncSequoiaToOffsite.sh
labeling. If you fix labeling either using chcon or using restorecon, it
will have the correct labeling after reboot if it is defined in the policy.
$ matchpathcon PATHTO/RsyncSequoiaToOffsite.sh
Thanks.
Thanks Miroslav, I think that is exactly what I was looking for. But
interestingly enough the problem was not quite what I initially thought
it was. I have Webmin installed on this box and setup my cron's through
the Webmin interface. When I manually kicked off this cron it gave the
SE Linux errors. But if I don't do it manually and let it run when
scheduled there is no error. So the issue I was seeing must somehow be
related to, or intiated by, the Webmin interface.
Jeff
--
Jeff Boyce
Meridian Environmental
www.meridianenv.com
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
