Signal problem

Signal problem

[Steve G]

Hello,

I ran across a problem while working on the audit code that has SE Linux
implications. The function security_task_kill does not hook all paths for signal 
entry/delivery. Just to make sure you know the piece of code I'm talking 
about:

http://lxr.linux.no/source/kernel/signal.c#L630

Some background -- we have a CAPP requirement to identify the sender of the 
TERM signal to the audit daemon. We placed a hook inside check_kill_permission().
It was called on a PPC, but my i686 kernel never sees it. I think there is some
arch specific code that changes how signals are delivered on ix86.

My test was simply /etc/rc.d/init.d/auditd stop
and then look for a message stating the shutdown signal was received.

Using strace, the usual entry method was syscall 37 (kill). After that who knows
what the code path is? I'm moving the audit hook to a whole new place 
to solve our problem. But I thought you might want to know about this since 
security_task_kill appears to be not hooking signals on all platforms.

-Steve Grubb

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Signal problem

[Stephen Smalley]

On Tue, 2005-04-26 at 12:23 -0700, Steve G wrote:
> Hello,
> 
> I ran across a problem while working on the audit code that has SE Linux
> implications. The function security_task_kill does not hook all paths for signal 
> entry/delivery. Just to make sure you know the piece of code I'm talking 
> about:
> 
> http://lxr.linux.no/source/kernel/signal.c#L630
> 
> Some background -- we have a CAPP requirement to identify the sender of the 
> TERM signal to the audit daemon. We placed a hook inside check_kill_permission().
> It was called on a PPC, but my i686 kernel never sees it. I think there is some
> arch specific code that changes how signals are delivered on ix86.
> 
> My test was simply /etc/rc.d/init.d/auditd stop
> and then look for a message stating the shutdown signal was received.
> 
> Using strace, the usual entry method was syscall 37 (kill). After that who knows
> what the code path is? I'm moving the audit hook to a whole new place 
> to solve our problem. But I thought you might want to know about this since 
> security_task_kill appears to be not hooking signals on all platforms.

Hmmmm...how certain are you?  Basic testing of signal controls and
auditing (via SELinux) seems to be working as expected here on x86.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Signal problem

[Stephen Smalley]

On Tue, 2005-04-26 at 12:23 -0700, Steve G wrote:
> Some background -- we have a CAPP requirement to identify the sender of the 
> TERM signal to the audit daemon. We placed a hook inside check_kill_permission().
> It was called on a PPC, but my i686 kernel never sees it. I think there is some
> arch specific code that changes how signals are delivered on ix86.
> 
> My test was simply /etc/rc.d/init.d/auditd stop
> and then look for a message stating the shutdown signal was received.

Isn't this unreliable anyway, e.g. your hook might queue up the audit
message for processing by auditd, but auditd gets the signal before it
handles the message and exits without emptying the queue?

-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Signal problem

[Chris Wright]

* Stephen Smalley (sds@tycho.nsa.gov) wrote:
> > Using strace, the usual entry method was syscall 37 (kill). After that who knows
> > what the code path is? I'm moving the audit hook to a whole new place 
> > to solve our problem. But I thought you might want to know about this since 
> > security_task_kill appears to be not hooking signals on all platforms.

I think the hook is in the right spot.

> Hmmmm...how certain are you?  Basic testing of signal controls and
> auditing (via SELinux) seems to be working as expected here on x86.

Working fine here as well.  I see the signal get sent each time I try
it.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Signal problem

[Chris Wright]

* Stephen Smalley (sds@tycho.nsa.gov) wrote:
> On Tue, 2005-04-26 at 12:23 -0700, Steve G wrote:
> > Some background -- we have a CAPP requirement to identify the sender of the 
> > TERM signal to the audit daemon. We placed a hook inside check_kill_permission().
> > It was called on a PPC, but my i686 kernel never sees it. I think there is some
> > arch specific code that changes how signals are delivered on ix86.
> > 
> > My test was simply /etc/rc.d/init.d/auditd stop
> > and then look for a message stating the shutdown signal was received.
> 
> Isn't this unreliable anyway, e.g. your hook might queue up the audit
> message for processing by auditd, but auditd gets the signal before it
> handles the message and exits without emptying the queue?

Ah, right.  That's the issue Steve's been wrestling with.  There's not a nice
race free way to ensure that audit message is delivered via auditd.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Signal problem

[Steve G]

>Isn't this unreliable anyway, e.g. your hook might queue up the audit
>message for processing by auditd, but auditd gets the signal before it
>handles the message and exits without emptying the queue?

The message would be in syslog in that scenario. It isn't there either.

-Steve


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Signal problem

[Chris Wright]

* Steve G (linux_4ever@yahoo.com) wrote:
> >Isn't this unreliable anyway, e.g. your hook might queue up the audit
> >message for processing by auditd, but auditd gets the signal before it
> >handles the message and exits without emptying the queue?
> 
> The message would be in syslog in that scenario. It isn't there either.

Upon termination, what's queued to the netlink socket but not yet
received is going to be lost, right?  Perhaps you need to be able to set
pid == 0, and still drain the fd when you recieve a TERM?

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Signal problem

[Steve G]

>Upon termination, what's queued to the netlink socket but not yet
>received is going to be lost, right?

I've also tested with nonfatal signals. This bug has been verified by other
people, too.

>Perhaps you need to be able to set pid == 0, and still drain the fd 
>when you recieve a TERM?

There's no way to drain the netlink socket in a race-free way. I've created a
whole new technique as a consequence. I'm just down to placing the hook.

-Steve

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Signal problem

[Chris Wright]

* Steve G (linux_4ever@yahoo.com) wrote:
> >Upon termination, what's queued to the netlink socket but not yet
> >received is going to be lost, right?
> 
> I've also tested with nonfatal signals. This bug has been verified by other
> people, too.

Nonfatal signals are delivered to auditd, but don't generate the audit
record?  Is it being filtered away?

> >Perhaps you need to be able to set pid == 0, and still drain the fd 
> >when you recieve a TERM?
> 
> There's no way to drain the netlink socket in a race-free way. I've created a
> whole new technique as a consequence. I'm just down to placing the hook.

If you first set audit_pid to 0, all future messages will go to syslog.  It's
only current netlink socket queue that needs to be drained.  So there's
no livelock issue, just a race against the typical 5 seconds or whatever
it is for init scripts between TERM and KILL while you madly drain the
queue.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Signal problem

[Stephen Smalley]

On Tue, 2005-04-26 at 13:18 -0700, Steve G wrote:
> >Isn't this unreliable anyway, e.g. your hook might queue up the audit
> >message for processing by auditd, but auditd gets the signal before it
> >handles the message and exits without emptying the queue?
> 
> The message would be in syslog in that scenario. It isn't there either.

Not necessarily; it could be queued on the netlink socket while
audit_pid was still non-zero, and then the signal is received and auditd
doesn't drain it properly. 

Trivial test for you would be to make your original hook call printk()
instead of audit_log*, and see if you get the message
in /var/log/messages or dmesg as expected.  In any event, I definitely
get SELinux permission denials and audit messages via the existing
security hook there for signal delivery.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.