First selinux problem, help!

[Daniel J Walsh]

Mark Haney wrote:
> Paul Howarth wrote:
>> Mark Haney wrote:
>>> Paul Howarth wrote:
>>>> Mark Haney wrote:
>>>>> I just encountered my first problem with selinux.  As I'm just now 
>>>>> losing my selinux virginity, I need help.  I have a process that I 
>>>>> can't kill since apparently the SIGKILL permission wasn't granted 
>>>>> to it.  How do I go about fixing that?
>>>>
>>>> You need to post the selinux denial message you're getting, so that 
>>>> we can see what is trying to send a signal to what.
>>>>
>>>> Paul.
>>>>
>>> Duh.  Sorry.  I'm trying to do about a million things here.  Here it 
>>> is:
>>>
>>> Nov  8 10:34:26 localhost kernel: audit(1163000066.441:216): avc:  
>>> denied  { sigkill } for  pid=28872 comm="bash" 
>>> scontext=user_u:system_r:unconfined_t:s0 
>>> tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
>>>
>>> What I'm trying to kill is a perl script (rsnapshot).
>>
>> Well that's a curious one. It would be allowed by policy here. Try 
>> piping that error log entry through /usr/sbin/audit2why at your end.
>>
>> Paul.
>>
> /usr/sbin/audit2why < audit.meh
> Nov  8 10:34:26 localhost kernel: audit(1163000066.441:216): avc:  
> denied  { sigkill } for  pid=28872 comm="bash" 
> scontext=user_u:system_r:unconfined_t:s0 
> tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=process
>        Was caused by:
>                Constraint violation.
>                Check policy/constraints.
>                Typically, you just need to add a type attribute to the 
> domain to satisfy the constraint.
>
>
> This is what I get when I piped it through audit2why.
>
>
This is a problem with MCS.  Basically you are running an unconfined 
domain at

user_u:system_r:unconfined_t:s0  (s0 is sometimes referred to as SystemLow)

The process you are trying to kill is running with a range.

root:system_r:unconfined_t:s0-s0:c0.c255  (SystemLow-SystemHigh)

In this version of the policy, there is a constraint that says the 
domain (scontext) sending the signal needs to "dominate"  the target 
domain (tcontext).

Since the process does not you get the denial.

Later versions of policy have fixed this problem

You can also change your login to allow you to login in this range.

semanage login -a -r SystemLow-SystemHigh dwalsh

Or if you want all users to have it

semanage login -m -r SystemLow-SystemHigh __default__