3

A friend of mine had trouble with SELinux. The server is configured with SELinux in enforcing mode, using the targeted policy.

When using Puppet, restorecon or chcon, he had errors like this, even if SELinux was not in enforcing mode

# chcon -t oddjob_t /etc/tt 
chcon: failed to change context of `/etc/oddjobd.conf.d' to `unconfined_u:object_r:oddjob_t:s0': Permission denied 

The /var/log/audit/audit.log contained:

type=AVC msg=audit(1429628369.080:338935): avc:  denied  { relabelto } for  pid=3629 comm="chcon" name="oddjobd.conf.d" dev=dm-0 ino=39413 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:oddjob_t:s0 tclass=dir 
type=SYSCALL msg=audit(1429628369.080:338935): arch=c000003e syscall=188 success=no exit=-13 a0=12f20e0 a1=3edf0162d9 a2=12f3620 a3=22 items=0 ppid=1206 pid=3629 auid=2006 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=25771 comm="chcon" exe="/usr/bin/chcon" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) 

In a similar way, restorecon failed:

# restorecon -Rv /etc 
restorecon reset /etc/oddjobd.conf.d context system_u:object_r:etc_t:s0->system_u:object_r:oddjob_t:s0 
restorecon set context /etc/oddjobd.conf.d->system_u:object_r:oddjob_t:s0 failed:'Permission denied' 

The /var/log/audit/audit.log contained:

type=AVC msg=audit(1429628361.258:338934): avc:  denied  { relabelto } for  pid=3627 comm="restorecon" name="oddjobd.conf.d" dev=dm-0 ino=39409 scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 tcontext=system_u:object_r:oddjob_t:s0 tclass=dir 
type=SYSCALL msg=audit(1429628361.258:338934): arch=c000003e syscall=189 success=no exit=-13 a0=7fdb4b1d5190 a1=7fdb49e762d9 a2=7fdb4b1d50f0 a3=1e items=0 ppid=1206 pid=3627 auid=2006 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=25771 comm="restorecon" exe="/sbin/setfiles" subj=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 key=(null)

He was logged-in as root. The bash shell was unconfined (id -Z).

So what was wrong?

1 Answer 1

6

Well, it turns out that my friend was just trying to use a file type which is invalid (oddjob_t is a process context, not a file context!)

Changing the context type of that directory to any other type was working fine (like chcon -t etc_t /etc/oddjobd.conf.d).

One can use seinfo to check which file types exists:

# seinfo -afile_type -x | grep "oddjob"
      oddjob_var_run_t 
      oddjob_exec_t 
      oddjob_mkhomedir_exec_t 

Running restorecon was also failing because my friend had inserted an invalid file context, with:

semanage fcontext --add -t oddjob_t "/etc/oddjobd.conf.d(/.*)?"

So I removed that incorrect rule (the rule wasn't needed at all):

semanage fcontext --list | grep "oddjob_t"
semanage fcontext -d -t oddjob_t "/etc/oddjobd.conf.d(/.*)?"

P.S. I found this blog post very useful to solve this issue Dan Walsh's Blog: SELinux Types Revisited.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .