# selinux file wrong context when viewed as non-root

## feystorm

I have a file which when I view the selinux context as my personal account, it shows up as "system_u:object_r:unlabeled_t", but when viewed as root, it shows up as "system_u:system_r:backup_exec_t" (which is correct).

```
phemmer@storm ~ # ls -lZi /usr/local/sbin/sysbkup

539394057 -rwxr-xr-x. 1 root root system_u:object_r:unlabeled_t 5140 2012/01/01-14:43:20 /usr/local/sbin/sysbkup*

root@storm ~ # ls -lZi /usr/local/sbin/sysbkup

539394057 -rwxr-xr-x. 1 root root system_u:system_r:backup_exec_t 5140 2012/01/01-14:43:20 /usr/local/sbin/sysbkup*
```

I obtained the backup_exec_t context from building and installing the selinux policy module "backup" from tresys' refpolicy (not available as an ebuild it seems). This is ultimately for a cron job which is backing up my system.

Did I miss some step when installing the policy module?Last edited by feystorm on Sat Jan 21, 2012 4:05 pm; edited 2 times in total

----------

## Wormo

 *feystorm wrote:*   

> 
> 
> Did I miss some step when installing the policy module?

 

No, loading the policy module is pretty much an all-or-nothing operation. 

Perhaps the policy is not allowing non-admin users to see the real attributes of this file? I've seen plenty of cases where the file attributes were completely unviewable by unprivileged users, although not quite like this where the wrong context is seen... anyways check your audit log to see if there are some AVC denials with respect to your normal user examining the file.

----------

## feystorm

Nothing appears in the log when I do the `ls` as non-root. I get messages when I try to cat it as non-root, but thats to be expected. Also when I do try to cat it, the message in the log has the unlabeled_t as the target context.

```
2012-01-16 07:50:57 kernel: [2977358.360536] type=1400 audit(1326718257.881:21537): avc:  denied  { open } for  pid=19878 comm="cat" name="sysbkup" dev=dm-0 ino=539394057 scontext=staff_u:staff_r:staff_t tcontext=system_u:object_r:unlabeled_t tclass=file
```

----------

## Wormo

Try running restorecon on the file and then retry this test to see how the context appears in the log

----------

## feystorm

Tried that. It shows up fine with its default context, but then shows up wrong when i chcon it again.

After restorecon

```
phemmer@storm ~ # ls -lZi /usr/local/sbin/sysbkup

539394057 -rwxr-xr-x. 1 root root system_u:object_r:bin_t 5140 2012/01/01-14:43:20 /usr/local/sbin/sysbkup*

root@storm ~ # ls -lZi /usr/local/sbin/sysbkup

539394057 -rwxr-xr-x. 1 root root system_u:object_r:bin_t 5140 2012/01/01-14:43:20 /usr/local/sbin/sysbkup*
```

Once it works I'll set the default file context for that path in my own policy module I keep for such things.

----------

## Wormo

Does backup_exec_t file context work properly for any files at all? Maybe that policy really is buggy...

----------

## feystorm

Yes, and some more info I just found.

It seems to only do this if I set the role of the file to system_r. If I leave it at object_r it works and shows up fine.

I'm really a noob at selinux kinda fumbling around, but I'm guessing its like that because the system_r role doesnt have permission to transition to backup_t. But this is just a guess, still fuzzy on how some of it ties together.

----------

## Wormo

The role on files is not supposed to matter, but the convention is to leave them as object_r. It sounds like there may be a bug in changing that default to something else -- so don't do that  :Wink: 

----------

## feystorm

Yes sir   :Smile: 

Thanks for the assistance

----------

## feystorm

I'm yanking the "[solved]" tag back off this because that solution seems to be inappropriate. The reason is my backup script has to run lvm commands to take a snapshot of the system. It also runs mdadm to dump md raid info. Without transitioning into the lvm and mdadm domains, selinux wants to block everything.

Now refpolicy has a couple of macros to grant certain roles the ability to transition to the lvm and mdadm domains. As such it just feels like granting the 'object_r' role the ability to transition is a bad idea if everything has the object_r role. It really does seem like the system_r is needed here (or another higher-level role).

----------

