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. > -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
