9:48 a.m.
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?
--
Ceterum censeo, Carthago delenda est.
Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
9:51 a.m.
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.
9:57 a.m.
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).
--
Ceterum censeo, Carthago delenda est.
Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
10:04 a.m.
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.
10:28 a.m.
On Wed, 8 Nov 2006, Paul Howarth wrote:
Mark Haney wrote:
> 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.
You are trying to send the signal as root (ie. it is worth double checking
you aren't doing something that ordinary linux would block)?
It may also be worth checking what selinux type you are running - for most
circumstances "targeted" is the right choice - the other options
"strict"
and "mls" are probably too paranoid for most purposes.
Michael Young
10:36 a.m.
M A Young wrote:
On Wed, 8 Nov 2006, Paul Howarth wrote:
> Mark Haney wrote:
>
>> 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.
>
You are trying to send the signal as root (ie. it is worth double checking
you aren't doing something that ordinary linux would block)?
It may also be worth checking what selinux type you are running - for most
circumstances "targeted" is the right choice - the other options
"strict"
and "mls" are probably too paranoid for most purposes.
Michael Young
Yes, I'm trying to send the signal as root. The process itself is owned
and run by root, so I don't think that should be a problem. As for
which type of selinux I'm running, how do I check that? I'm pretty sure
I'm using targeted, but can't say for certain.
--
Ceterum censeo, Carthago delenda est.
Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
10:55 a.m.
On Wed, 8 Nov 2006, Mark Haney wrote:
M A Young wrote:
> You are trying to send the signal as root (ie. it is worth double checking
> you aren't doing something that ordinary linux would block)?
> It may also be worth checking what selinux type you are running - for most
> circumstances "targeted" is the right choice - the other options
"strict"
> and "mls" are probably too paranoid for most purposes.
>
> Michael Young
>
>
Yes, I'm trying to send the signal as root. The process itself is owned
and run by root, so I don't think that should be a problem. As for
which type of selinux I'm running, how do I check that? I'm pretty sure
I'm using targeted, but can't say for certain.
The sestatus command will tell you for sure.
Michael Young
11 a.m.
Mark Haney wrote:
M A Young wrote:
> On Wed, 8 Nov 2006, Paul Howarth wrote:
>
>> Mark Haney wrote:
>>
>>> 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.
>>
>
> You are trying to send the signal as root (ie. it is worth double
> checking
> you aren't doing something that ordinary linux would block)?
> It may also be worth checking what selinux type you are running - for
> most
> circumstances "targeted" is the right choice - the other options
"strict"
> and "mls" are probably too paranoid for most purposes.
>
> Michael Young
>
>
Yes, I'm trying to send the signal as root. The process itself is owned
and run by root, so I don't think that should be a problem. As for
which type of selinux I'm running, how do I check that? I'm pretty sure
I'm using targeted, but can't say for certain.
The "sestatus" command will tell you which policy you're using.
Paul.
10:35 a.m.
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.
--
Ceterum censeo, Carthago delenda est.
Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
11:18 a.m.
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__
12:21 p.m.
Daniel J Walsh wrote:
> /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__
/usr/sbin/semanage: Login mapping for root is already defined
This is what I get when I try to set this up for root. I would have
assumed root had that authority anyway. This still doesn't explain why
I can't kill this process.
And when I checked with sestatus this is what I get:
[root@blowingrock ~]# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 20
Policy from config file: targeted
--
Ceterum censeo, Carthago delenda est.
Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
3:17 p.m.
Mark Haney wrote:
Daniel J Walsh wrote:
>> /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__
>
/usr/sbin/semanage: Login mapping for root is already defined
This is what I get when I try to set this up for root. I would have
assumed root had that authority anyway. This still doesn't explain
why I can't kill this process.
And when I checked with sestatus this is what I get:
[root@blowingrock ~]# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 20
Policy from config file: targeted
If you log in directly as root, you should get the correct context, if
you log in as a normal user and then execute su or sudo you will not.
semanage login -l
Will list your login records
semanage login -m
will modify
semanage login -a
will add
If you do not have a login record for a particular user, they will
default to __default__
3:20 p.m.
Daniel J Walsh wrote:
>
If you log in directly as root, you should get the correct context, if
you log in as a normal user and then execute su or sudo you will not.
I had no clue about that. I assumed (and wrongly obviously) that root,
no matter how you got there would get the correct context. Will su - or
sudo su - give you the correct context?
semanage login -l
Will list your login records
semanage login -m
will modify
semanage login -a
will add
If you do not have a login record for a particular user, they will
default to __default__
Thanks for all the info. I'll be keeping this for reference.
--
Ceterum censeo, Carthago delenda est.
Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
3:48 p.m.
Mark Haney wrote:
Daniel J Walsh wrote:
>>
>
> If you log in directly as root, you should get the correct context,
> if you log in as a normal user and then execute su or sudo you will not.
>
I had no clue about that. I assumed (and wrongly obviously) that
root, no matter how you got there would get the correct context. Will
su - or sudo su - give you the correct context?
No. Sorry. BTW this is fixed in
FC6 and RHEL5.
> semanage login -l
>
> Will list your login records
>
> semanage login -m
>
> will modify
>
> semanage login -a
>
> will add
>
> If you do not have a login record for a particular user, they will
> default to __default__
>
Thanks for all the info. I'll be keeping this for reference.
6401
days inactive
6401
days old
13 comments
4 participants
participants (4)
-
Daniel J Walsh -
M A Young -
Mark Haney -
Paul Howarth