Writing a program to monitor the SELinux log

Writing a program to monitor the SELinux log

[Jason Axelson]

Hi,

I am writing a program that will monitor the SELinux log for AVC violations
and deal with them appropriately. Currently I am looking at approaches to
monitor the SELinux log.

One approach is to do raw monitoring of /var/log/audit/audit.log with
something like:
    tail -f /var/log/audit/audit.log | ausearch -m avc

A second approach may be to implement an SETroubleShoot plugin:
https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20Overview

I'm kind of leaning towards an SETroubleShoot plugin since it seems like less
new development and the infrastructure seems to be already there.

Is this a valid approach? Is there a better way?

Thanks,
Jason

--
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: Writing a program to monitor the SELinux log

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/11/2011 11:07 PM, Jason Axelson wrote:
> Hi,
> 
> I am writing a program that will monitor the SELinux log for AVC
> violations and deal with them appropriately. Currently I am looking
> at approaches to monitor the SELinux log.
> 
> One approach is to do raw monitoring of /var/log/audit/audit.log
> with something like: tail -f /var/log/audit/audit.log | ausearch -m
> avc
> 
> A second approach may be to implement an SETroubleShoot plugin: 
> https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20Overview
>
>  I'm kind of leaning towards an SETroubleShoot plugin since it
> seems like less new development and the infrastructure seems to be
> already there.
> 
> Is this a valid approach? Is there a better way?
> 
> Thanks, Jason
> 
> -- 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.
> 
> 
I would say either just write an setroubleshoot plugin or copy the
code in sedispatch from setroubleshoot to build your own audit
dispatcher, that watches for SELinux messages.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6VifkACgkQrlYvE4MpobM27QCcCOIwbMVqj4sdBmhwOuUZ0G1f
jOYAoKtoyaQVKo04heYaRAfoI2QMNKfw
=0DCd
-----END PGP SIGNATURE-----

--
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: Writing a program to monitor the SELinux log

[Jason Axelson]

On Wed, Oct 12, 2011 at 2:37 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> On 10/11/2011 11:07 PM, Jason Axelson wrote:
>> Hi,
>>
>> I am writing a program that will monitor the SELinux log for AVC
>> violations and deal with them appropriately. Currently I am looking
>> at approaches to monitor the SELinux log.
>>
>> One approach is to do raw monitoring of /var/log/audit/audit.log
>> with something like: tail -f /var/log/audit/audit.log | ausearch -m
>> avc
>>
>> A second approach may be to implement an SETroubleShoot plugin:
>> https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20Overview
>>
>>  I'm kind of leaning towards an SETroubleShoot plugin since it
>> seems like less new development and the infrastructure seems to be
>> already there.
>>
>> Is this a valid approach? Is there a better way?
>>
> I would say either just write an setroubleshoot plugin or copy the
> code in sedispatch from setroubleshoot to build your own audit
> dispatcher, that watches for SELinux messages.

Thanks for all of the suggestions!

After some consideration I think I will either copy sedispatch or
write my own version of sedispacth (it's only 266 lines after all!).
This was mainly chosen because it is simple, performant, and doesn't
bring in unnecessary dependencies.

Thanks,
Jason


--
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: Writing a program to monitor the SELinux log

[Patrick K., ITF]

Hi Jason,

I believe you actually gave the answer yourself,

SeTroubleShoot tends to achieve exactly what you want, with much less 
effort if you program in Python,

you can add your plugins,

the raw processing approach requires more effort to achieve what 
SeTroubleshoot already established

Which one is "better" actually depends on what you want to achieve, your 
deadline and programming/scripting language that you want to work with

Sincerely,

Patrick K.

On 10/11/2011 11:07 PM, Jason Axelson wrote:
> Hi,
>
> I am writing a program that will monitor the SELinux log for AVC violations
> and deal with them appropriately. Currently I am looking at approaches to
> monitor the SELinux log.
>
> One approach is to do raw monitoring of /var/log/audit/audit.log with
> something like:
>      tail -f /var/log/audit/audit.log | ausearch -m avc
>
> A second approach may be to implement an SETroubleShoot plugin:
> https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20Overview
>
> I'm kind of leaning towards an SETroubleShoot plugin since it seems like less
> new development and the infrastructure seems to be already there.
>
> Is this a valid approach? Is there a better way?
>
> Thanks,
> Jason
>
> --
> 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.

--
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: Writing a program to monitor the SELinux log

[LC Bruzenak]

On Tue, 2011-10-11 at 17:07 -1000, Jason Axelson wrote:

> 
> Is this a valid approach? Is there a better way?
> 
> Thanks,
> Jason

Jason,

I did this exact thing.
I named it "avcAssassin".
:)

The reason I did this is because when my group delivers a system which
cannot be easily changed, we need insurance that some untested code path
cannot launch a crippling stream of useless AVCs. After seeing this
happen, I wrote the avcAssassin code.

The way I did this is to use the same socket as used by the
SETroubleshooter but all the code is in C. I do not use the
troubleshooter for delivered system code.

I use the audit auparse C library.
I wanted it to use little CPU as possible.

So what I do is this:

Launch a process which just reads the audit stream.
Launch a child which waits for those events.
Connect them via non-blocking pipe; it's lossy on purpose. 

Parent looks for avc events and only sends timestamp and PID to child. 
Child reads avs and keeps a configurable list (default 5) of processes
generating avcs. There is a timer window (default 2 seconds) where the
child checks the counts and does something heinous (kills them) if they
are over the configurable threshold (default is 100/second). Also there
is a configurable exclusion list in case you don't want them killed.

Everything is asynchronous and non-blocking. If the pipe is full the
parent doesn't care. 

The child does all the work of matching PID to process name, counting
AVCs, submitting an audit event about it, etc. 

The idea is that in the end you have a lossy time-sliced sample of avc
events that are actionable because you have defined it that way. It's a
brutal approach but then again if you have all your policy coverage
perfect, it will not do anything. Because it is launched as a service it
can be disabled easily. Some drawbacks are that it really only works on
persistent processes. Ones which spawn rapidly and spew avcs will burden
the child process but not be detected since the PIDs will differ.

Let me know if you want the code; it isn't perfect or ready for the
world but it does perform as described (so far). 
Hopefully this helps your decision.

If you are fluent in Python (I'm not) then maybe a SETroubleshoot plugin
is a better way to go, with the benefit that it might get upstreamed.

R,
LCB

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.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.