Issue with SELinux and BackupPC backup directory at non-standard location

[Jeff Boyce]

Dominick -

Thanks for the education.  Your advice was following the direction I was 
thinking to go, but that gave me confirmation that I was making the right 
decision.  In the end I checked to see if there was a specific file context 
for BackupPC (#seinfo -t will list all the type contexts available).  Since 
there was not a specific file context for BackupPC, I elected to apply the 
same context that is at the default BackupPC file storage location to my 
non-standard location at /bkupdata.  So in the end this was solved by 
applying the following two commands:

#semanage fcontext -a -e /var/lib/BackupPC /bkupdata
#restorecon -R -v /bkupdata

I then rebooted the system just to make sure that everything checks out 
after a reboot, and it works as expected.  Thanks for your assistance.

Jeff Boyce
Meridian Environmental
www.meridianenv.com



----- Original Message ----- 
From: "Dominick Grift" <dominick.grift at gmail.com>
To: "Jeff Boyce" <jboyce at meridianenv.com>
Cc: "SELinux Fedora List" <selinux at lists.fedoraproject.org>
Sent: Saturday, March 16, 2013 1:55 AM
Subject: Re: Issue with SELinux and BackupPC backup directory at 
non-standard location


> On Fri, 2013-03-15 at 16:14 -0700, Jeff Boyce wrote:
>
>> In reviewing my SELinux contexts listed above, I noticed that the group
>> assignment for the directories under /bkupdata is root. I have 
>> subsequently
>> changed them to backuppc, and shutdown the backuppc service, shutdown and
>> restarted the http service, then restarted the backuppc service. The same
>> errors persist after this change, so the issue was not just with an
>> incorrect group setting.
>>
>> Here is a representative sample of the SELinux audit messages that are
>> occurring:
>>
>
> The AVC denials all have some things in common:
>
> 1. the source type of the operation is httpd_t
> 2. the target type of the operation is default_t
>
> httpd_t is the webserver process type.
>
> default_t is a special type. This type is assigned to locations unknown
> to SELinux.
>
> In this case SELinux is not aware of your exotic "/bkupdata" mountpoint.
>
> Everything on a system is classified using types. That way SELinux knows
> if and what access it should grant to any given source.
>
> So what you should do is, you should classify /bkupdata and the content
> in there by assigning it an appropriate type.
>
> You should use the existing type for this.
>
> So basically you should look at a existing location that is similar to
> your new location and consider using the same type.
>
> There is a command that makes it easy to "clone" file contexts but it
> has its limits (you cannot nest them and so use them wisely)
>
> I will give you one very simple example:
>
> lets say that the /bkupdata is really just the same as /var but just in
> a exotic location. That would mean that you could clone the file
> contexts for /var and use them on /bkupdata as well.
>
> man semanage has an example of how to use the fcontext uquivalent
> functionality:
>
> # semanage fcontext -a -e /var /bkupdata
> # restorecon -R -v /bkupdata
>
> That will make the contexts of bkupdata equivalent to that of /var
>
> Remember though that you cannot nest them.
>
> Its up to you to find the appropriate types to use. I do not know the
> properties of your /bkupdata location.
>
> I can see a backup directory and i also see that httpd_t is trying to
> access content on your /bkupdata mountpount.
>
> You may be able to fix this by just using the backupc_var_lib_t ( i am
> not even sure if that type exists) type for the whole mountpount:
>
> semanage fcontext -a -t backuppc_var_lib_t "/bkupdata(/.*)?"
> restorecon -R -v -F /bkupdata
>
>> ----
>>
>> time->Thu Mar 14 13:35:51 2013
>>
>> type=SYSCALL msg=audit(1363293351.295:27283): arch=c000003e syscall=2
>> success=no exit=-13 a0=1437b70 a1=0 a2=1b6 a3=3c1711dbe0 items=0 
>> ppid=1813
>> pid=4379 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 
>> egid=48
>> sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin."
>> exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)
>>
>> type=AVC msg=audit(1363293351.295:27283): avc:  denied  { read } for
>> pid=4379 comm="BackupPC_Admin." name="backups" dev=vdd1 ino=4218673
>> scontext=system_u:system_r:httpd_t:s0
>> tcontext=system_u:object_r:default_t:s0 tclass=file
>>
>> ----
>>
>> time->Thu Mar 14 13:35:51 2013
>>
>> type=SYSCALL msg=audit(1363293351.292:27282): arch=c000003e syscall=2
>> success=no exit=-13 a0=1437b10 a1=0 a2=1b6 a3=3c1711dbe0 items=0 
>> ppid=1813
>> pid=4379 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 
>> egid=48
>> sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin."
>> exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)
>>
>> type=AVC msg=audit(1363293351.292:27282): avc:  denied  { read } for
>> pid=4379 comm="BackupPC_Admin." name="LOCK" dev=vdd1 ino=4194307
>> scontext=system_u:system_r:httpd_t:s0
>> tcontext=system_u:object_r:default_t:s0 tclass=file
>>
>> ----
>>
>> time->Thu Mar 14 13:36:01 2013
>>
>> type=SYSCALL msg=audit(1363293361.526:27285): arch=c000003e syscall=4
>> success=no exit=-13 a0=1630140 a1=1569130 a2=1569130 a3=21 items=0 
>> ppid=1806
>> pid=4400 auid=4294967295 uid=496 gid=48 euid=496 suid=496 fsuid=496 
>> egid=48
>> sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="BackupPC_Admin."
>> exe="/usr/bin/perl" subj=system_u:system_r:httpd_t:s0 key=(null)
>>
>> type=AVC msg=audit(1363293361.526:27285): avc:  denied  { getattr } for
>> pid=4400 comm="BackupPC_Admin." path="/bkupdata/pc/jab-opti755/backups"
>> dev=vdd1 ino=4218673 scontext=system_u:system_r:httpd_t:s0
>> tcontext=system_u:object_r:default_t:s0 tclass=file
>>
>> ----
>>
>>
>> I have read through the RedHat SELinux users guide and understand from 
>> this
>> and looking at the above messages that my target context is probably not
>> what it should be for this.  I am hoping someone can guide me to get this
>> corrected in a proper way without making a blanket permissive policy. 
>> Also
>> I would like to make sure that if I have to expand my partition again, I
>> don't want to have to go through the same pain of discovering the 
>> problem,
>> or have it fixed so that the problem doesn't re-occur.  If any additional
>> information is needed please let me know.
>>
>> Please CC me directly on any replies as I am only subscribed to the daily
>> digest.  Thanks.
>>
>> Jeff Boyce
>> Meridian Environmental
>> www.meridianenv.com
>>
>> --
>> selinux mailing list
>> selinux at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
>