user message limits
by LC Bruzenak
I know I can go look at the code, however I figured I'd ask here first
about the limits on the user message in both audit_log_user_message and
ausearch.
With audit_log_user_message the maximum length allowed appears to be
around MAX_AUDIT_MESSAGE_LENGTH-100. I think it may depend on the
executable name length (and other stuff auto-pushed into the string)
which is why I say "around".
Even when I get a successful return value (from audit_log_user_message),
I don't get my string back out in "ausearch" unless it is WAY smaller -
~1K or less I think.
Any ideas/thoughts?
This is the latest (1.7.11-2) audit package.
Thx,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
11 years, 9 months
AUDIT_SIGNAL_INFO
by Matthew Booth
Under what circumstances will the RHEL 4 kernel generate a message of
type AUDIT_SIGNAL_INFO? My understanding is that it should be sent when
a process sends a signal to the audit daemon, however I have not
observed that. Any ideas?
Thanks,
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
13 years
Near Term Audit Road Map
by Steve Grubb
Hi,
With the proposals sent to the list, I wanted to talk about how this might
play out code-wise. With regard to the current code base, I am working on a
1.8 release. This would represent finishing the remote logging app and
nothing more. The 1.8 series would become just an update series just like the
1.0.x series did.
In parallel with finishing remote logging, I would release a 2.0 version.
Patches applied to 1.8 would also be applied to 2.0. A 2.1 release would
signify the completion of remote logging that branch. I would recommend this
branch for all distributions pulling new code in.
The 2.0 branch will also have a couple more changes. I want to split up the
audit source code a little bit. I want to drop the system-config-audit code
and let it become standalone package updated and distributed separately.
I also want to drop all audispd-plugins in the 2.0 branch and have them
released separately. They cause unnecessary build dependencies for the audit
package.
During the work for a 2.2 release, I would also like to pull the audispd
program inside auditd. In the past, I tried to keep auditd lean and single
purpose, but with adding remote logging and kerberos support, we already have
something that is hard to analyze. So, to improve performance and decrease
system load, the audit daemon will also do event dispatching.
Would this proposal impact anyone in a Bad Way?
Thanks,
-Steve
13 years
RE: Linux-audit Digest, Vol 81, Issue 19
by Rye, Gene R.
Why not set up a cron job that will copy the contents of the audit.log
file and secure files to archive on a weekly basis? The files then
could be overwritten with the /dev/null file. This will ensure that the
data is captured in the event the autorotate fails.
-----Original Message-----
From: linux-audit-bounces(a)redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of
linux-audit-request(a)redhat.com
Sent: Thursday, June 30, 2011 12:00 PM
To: linux-audit(a)redhat.com
Subject: Linux-audit Digest, Vol 81, Issue 19
Send Linux-audit mailing list submissions to
linux-audit(a)redhat.com
To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/linux-audit
or, via email, send a message with subject or body 'help' to
linux-audit-request(a)redhat.com
You can reach the person managing the list at
linux-audit-owner(a)redhat.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linux-audit digest..."
Today's Topics:
1. Audit rotate vs log rotate questions (Dole, Patrick A.)
2. Re: Audit rotate vs log rotate questions (Steve Grubb)
----------------------------------------------------------------------
Message: 1
Date: Wed, 29 Jun 2011 18:10:44 -0500
From: "Dole, Patrick A." <Patrick.Dole(a)gd-ais.com>
To: "linux-audit(a)redhat.com" <linux-audit(a)redhat.com>
Subject: Audit rotate vs log rotate questions
Message-ID:
<5AE2942125A7394BB0DD5B9F32DF16921C0A1E10B9(a)EADC01-MABPRD11.ad.gd-ais.co
m>
Content-Type: text/plain; charset="us-ascii"
Hi,
I was hoping you could provide some help with audit rotation vs.
logrotate
I'm running REL 5 SElinux
In my daily.con I have 2 cron jobs that I believe should manage the
'audit.log' file; audit.cron and logrotate
My audit.cron includes:
service auditd rotate
Does this imply that the log always gets rotated, or is this based on
other conditional checks?
There are no other parameters in the audit.cron, so I don't see where
'max_log_size_action' or 'max_log_file_action' are checked.
Here is my auditd.conf
Also, I've read that cron doesn't like files with a period (.) in the
name - is this an issue with REL 5?
...
My Logrotate.conf is attached
My logrotate.d contains this file:
My basic questions is wouldn't the audit.cron, if it actually rotates
the log, preclude the logrotate from properly capturing the right log
files monthly?
Also, if I wanted to ensure no audit.log data ever gets deleted, could I
simply increase the 'rotate 12' statement to something like 'rotate 60'
to keep 5 years of data (provided the disk doesn't get full).
FYI, there is another utility that archives the log files and gives the
user the option to delete files after they are archived.
A response within a couple days, if possible, would be great.
Thanks for your help.
Pat Dole
General Dynamics AIS
14 years
Audit rotate vs log rotate questions
by Dole, Patrick A.
Hi,
I was hoping you could provide some help with audit rotation vs. logrotate
I'm running REL 5 SElinux
In my daily.con I have 2 cron jobs that I believe should manage the 'audit.log' file; audit.cron and logrotate
My audit.cron includes:
service auditd rotate
Does this imply that the log always gets rotated, or is this based on other conditional checks?
There are no other parameters in the audit.cron, so I don't see where 'max_log_size_action' or 'max_log_file_action' are checked.
Here is my auditd.conf
Also, I've read that cron doesn't like files with a period (.) in the name - is this an issue with REL 5?
...
My Logrotate.conf is attached
My logrotate.d contains this file:
My basic questions is wouldn't the audit.cron, if it actually rotates the log, preclude the logrotate from properly capturing the right log files monthly?
Also, if I wanted to ensure no audit.log data ever gets deleted, could I simply increase the 'rotate 12' statement to something like 'rotate 60' to keep 5 years of data (provided the disk doesn't get full).
FYI, there is another utility that archives the log files and gives the user the option to delete files after they are archived.
A response within a couple days, if possible, would be great.
Thanks for your help.
Pat Dole
General Dynamics AIS
14 years
Auditd filtering
by Nick Stires
I've run into an issue where I have a network of 55 RHEL 5 boxes that each run monitoring software such as nagios and ganglia and are generating roughly 1.2G of audit logs per day. Much of these entries are from the monitoring functionality. I've had to disable audisp, centralized auditing, due to hard drive and networking limitations.
We're finding that 95% of the audit events fall into three unique events, each repeating causing a tail -f of the audit log to resemble the matrix. I've been Googling and reading posts off this site in attempt to write some filter policies to prevent these from writing to the log. I can safely filter out 159 since its a minor hit (change time). The others are more critical, such as file opens.
I started with a generic filter for all syscall events, this cut it down adequately, but we no longer captured the items we wanted to.
Here's some example logs for the two events we are trying to trim down:
################
################
Netstat sample
################
################
type=SYSCALL msg=audit(1307462086.972:1619017): arch=c000003e syscall=2 success=no exit=-2 a0=6d9c790 a1=0 a2=0 a3=3074f234f3 items=2 ppid=4945 pid=32700 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="netstat" exe="/bin/netstat" subj=kernel key=(null)
type=CWD msg=audit(1307462086.972:1619017): cwd="/"
type=PATH msg=audit(1307462086.972:1619017): item=0 name="/usr/share/locale/en.utf8/LC_MESSAGES/net-tools.mo"
type=PATH msg=audit(1307462086.972:1619017): item=1 name="/usr/share/locale/en.utf8/LC_MESSAGES/net-tools.mo"
################
################
Ganglia Sample
################
################
type=SYSCALL msg=audit(1307462163.369:1620406): arch=c000003e syscall=2 per=400000 success=no exit=-2 a0=2aaab81124b8 a1=0 a2=1b6 a3=0 items=2 ppid=678 pid=681 auid=1002 uid=1002 gid=100 euid=1002 suid=1002 fsuid=1002 egid=100 sgid=100 fsgid=100 tty=(none) ses=641 comm="java" exe="/usr/java/jdk1.6.0_24/bin/java" subj=kernel key=(null)
type=CWD msg=audit(1307462163.369:1620406): cwd="/home/ganglia"
type=PATH msg=audit(1307462163.369:1620406): item=0 name="/proc/net/if_inet6"
type=PATH msg=audit(1307462163.369:1620406): item=1 name="/proc/net/if_inet6"
type=SYSCALL msg=audit(1307462163.365:1620404): arch=c000003e syscall=2 success=no exit=-20 a0=7fff922a6610 a1=10800 a2=7fff922a68f0 a3=22 items=2 ppid=703 pid=704 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="modprobe" exe="/sbin/modprobe" subj=kernel key=(null)
type=CWD msg=audit(1307462163.365:1620404): cwd="/"
type=PATH msg=audit(1307462163.365:1620404): item=0 name="/etc/modprobe.d/blacklist-firewire" inode=1049506 dev=08:07 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unlabeled
type=PATH msg=audit(1307462163.365:1620404): item=1 name="/etc/modprobe.d/blacklist-firewire"
type=SYSCALL msg=audit(1307462402.517:1626432): arch=c000003e syscall=2 per=400000 success=no exit=-2 a0=7fff089b2f60 a1=0 a2=2b20f5d60000 a3=62696c2f2e2e2f6e items=2 ppid=2805 pid=2807 auid=1002 uid=1002 gid=100 euid=1002 suid=1002 fsuid=1002 egid=100 sgid=100 fsgid=100 tty=(none) ses=644 comm="java" exe="/usr/java/jdk1.6.0_24/bin/java" subj=kernel key=(null)
type=CWD msg=audit(1307462402.517:1626432): cwd="/home/ganglia"
type=PATH msg=audit(1307462402.517:1626432): item=0 name="/usr/java/jdk1.6.0_24/bin/../lib/amd64/jli/x86_64/libpthread.so.0"
type=PATH msg=audit(1307462402.517:1626432): item=1 name="/usr/java/jdk1.6.0_24/bin/../lib/amd64/jli/x86_64/libpthread.so.0"
type=SYSCALL msg=audit(1307462402.517:1626433): arch=c000003e syscall=2 per=400000 success=no exit=-2 a0=7fff089b2f60 a1=0 a2=2b20f5d60000 a3=62696c2f2e2e2f6e items=2 ppid=2805 pid=2807 auid=1002 uid=1002 gid=100 euid=1002 suid=1002 fsuid=1002 egid=100 sgid=100 fsgid=100 tty=(none) ses=644 comm="java" exe="/usr/java/jdk1.6.0_24/bin/java" subj=kernel key=(null)
type=CWD msg=audit(1307462402.517:1626433): cwd="/home/ganglia"
type=PATH msg=audit(1307462402.517:1626433): item=0 name="/usr/java/jdk1.6.0_24/bin/../lib/amd64/jli/libpthread.so.0"
type=PATH msg=audit(1307462402.517:1626433): item=1 name="/usr/java/jdk1.6.0_24/bin/../lib/amd64/jli/libpthread.so.0"
type=SYSCALL msg=audit(1307462402.517:1626434): arch=c000003e syscall=2 per=400000 success=no exit=-2 a0=7fff089b2f60 a1=0 a2=2b20f5d60000 a3=65726a2f2e2e2f6e items=2 ppid=2805 pid=2807 auid=1002 uid=1002 gid=100 euid=1002 suid=1002 fsuid=1002 egid=100 sgid=100 fsgid=100 tty=(none) ses=644 comm="java" exe="/usr/java/jdk1.6.0_24/bin/java" subj=kernel key=(null)
type=CWD msg=audit(1307462402.517:1626434): cwd="/home/ganglia"
type=PATH msg=audit(1307462402.517:1626434): item=0 name="/usr/java/jdk1.6.0_24/bin/../jre/lib/amd64/jli/tls/x86_64/libpthread.so.0"
type=PATH msg=audit(1307462402.517:1626434): item=1 name="/usr/java/jdk1.6.0_24/bin/../jre/lib/amd64/jli/tls/x86_64/libpthread.so.0"
Exemption rules:
# a0=0x413586 appears to prevent proc tcp6 messages in the netstat sections
-a exit,never -F a0=0x413586 -F success=0
-a exit,never -F exit=-6 -F success=0
-a exit,never -F exit=-13 -F success=0
-a entry,never -S 159
# UID 1002 = ganglia user. These do not work as intended.
-a user,never -F auid=1002
-a user,never -F uid=1002
Any ideas on how I can target these audit logs for filtering?
Thanks!
Nicholas Stires
Principal Systems Engineer
Bingham Technical Solutions LLC
14 years
[PATCH] auditd - TTY support for audisp-prelude
by Matteo Sessa
Hi all,
Attached is a patch for auditd to add support for TTY audits ( pam_tty_audit session module ) to audisp-prelude.
Alerts are reported with:
alert.classification.text = "Keylogger"
alert.assessment.impact.severity = LOW
and actual keystrokes carried on alert.additional_data.
Attached you will find also a basic python commandline script to query keylogger data from prelude database.
Hope it helps.
Matteo Sessa
IT Systems Administrator
D.B.M. srl
Via Enrico Noe, 23
20133 Milano (MI), Italy
Landline: (+39) 02-266005-21
Mobile: (+39) 334-6220662
14 years
How to track process invocation history using audit
by Kohei KaiGai
Hi,
I tried to track what process launches what other programs using audit
mechanism.
Then, I want to write up a tree diagram using audit logs eventually.
However, the auditctl does not work as I expected.
I tried to track all the fork(2) system call to record relationship
between ppid and pid
on processes with a particular loginuid.
[root@ls3029v0 ~]# auditctl -a task,always -F arch=b64 -S fork -F auid=1234
Error: syscall auditing being added to task list
But, it does not works.
I also tried to use 'exit' list, but it seems to me the following rule
is ignored.
(tail -f /var/log/audit/audit.log does not report anything)
[root@ls3029v0 ~]# auditctl -a exit,always -F arch=b64 -S fork
What is the best way to track process invocation history using audit mechanism?
Thanks,
--
KaiGai Kohei <kaigai(a)kaigai.gr.jp>
14 years
Re: [PATCH 3rd revision] Add SELinux context support to AUDIT target
by Eric Paris
On Thu, Jun 9, 2011 at 8:28 AM, Patrick McHardy <kaber(a)trash.net> wrote:
> On 08.06.2011 21:39, Eric Paris wrote:
>> On Wed, Jun 8, 2011 at 3:28 PM, Steve Grubb <sgrubb(a)redhat.com> wrote:
>>> On Wednesday, June 08, 2011 03:08:38 PM Eric Paris wrote:
>>>> On Wed, Jun 8, 2011 at 3:00 PM, Mr Dash Four
>>>>
>>>> <mr.dash.four(a)googlemail.com> wrote:
>>>>>> int audit_log_secctx(struct auditbuffer *ab, u32 secid)
>>>>>> {
>>>>>> int len, rc;
>>>>>> char *ctx;
>>>>>>
>>>>>> rc = security_secid_to_secctx(sid, &ctx, &len);
>>>>>> if (rc) {
>>>>>> audit_panic("Cannot convert secid to context");
>>>>>> } else {
>>>>>> audit_log_format(ab, " subj=%s", ctx);
>>>>>> security_release_secctx(ctx, len);
>>>>>> }
>>>>>> return rc;
>>>>>> }
>>>>>>
>>>>>> Such a function could be used a couple of places in the audit code
>>>>>> itself.
>>>>>
>>>>> My view on this is that LSM error-handling should be part of LSM.
>>>>>
>>>>> I presume security_secid_to_secctx is going to be called from quite a few
>>>>> places (well, I know of at least two now and they have nothing to do with
>>>>> the LSM) and in my opinion it would be better if that error handling, if
>>>>> adopted, is implemented within the function itself - whether by calling
>>>>> another function, like the one you proposed above, or as part of the
>>>>> secctx retrieval - this could be open to interpretation, but the point I
>>>>> am trying to make is that whichever code security_secid_to_secctx is
>>>>> invoked from shouldn't be involved in reporting/handling (internal LSM)
>>>>> errors at all.
>>>>>
>>>>> I think I made that point in my previous post, but just wanted to make
>>>>> sure that is the case.
>>>>
>>>> The LSM might report and error. It's up to the caller to figure out
>>>> how to deal with that error. In this case we want to use the audit
>>>> system so it's up to the audit system how to handle that error.
>>>
>>> We are happy recording the failed number. Its the LSM people that say nuke the system.
>>> So, I would put that in security_secid_to_secctx() so that everyone knows whose
>>> requirements it was to do the nuclear option.
>>
>> If the number meets your requirements then the requirements are total
>> shit. The number has NO relation to the label on the object as
>> understood by the system. If audit has a requirement to always log
>> the label or call audit_panic(), its only option is to call
>> audit_panic().
>>
>> Exposing secids and internal representations of information to
>> userspace is always wrong. Full stop.
>>
>> I'd be willing to take a patch which caused security_secid_to_secctx()
>> to BUG() if it got an invalid secid. But on ENOMEM I'm going to just
>> push the error back up the stack. In that case audit has to decide
>> how to handle the situation. That secid is NOT the label associated
>> with the object and printing it to userspace is meaningless garbage.
>>
>> Just because audit did it wrong yesterday doesn't mean I'm going to
>> ACK more patches that do it wrong tomorrow. I don't care what some
>> arbitrary and obviously poorly thought out requirement document says.
>
> Just to make sure, so the conclusion is that the patch is fine as
> it is and anything related to unconvertible secids will be handled
> by SELinux internally?
>
No. This patch does not get my ACK. Steve is right that silently
dropping information is a big big no no for the audit system and
that's what this patch does. This cannot be wholly handled properly
inside the LSM either. I don't see any patch meeting everyone's
requirements outside of a new one that includes the audit helper I
suggested.
-Eric
14 years
