June 2011 - Linux-audit - Linux-Audit List Archives

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

12 years, 7 months

5
17
0 / 0

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, 11 months

3
4
0 / 0

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, 11 months

4
11
0 / 0

missing user authentication events.

by Robert Harris

14 years, 5 months

3
5
0 / 0

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, 10 months

2
1
0 / 0

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, 10 months

2
1
0 / 0

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, 10 months

2
1
0 / 0

[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, 10 months

2
1
0 / 0

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, 10 months

2
1
0 / 0

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, 10 months

3
8
0 / 0

Re: log files

by Pittigher, Raymond - ES

On 06/17/2011 02:56 PM, LC Bruzenak wrote: > On Fri, 2011-06-17 at 14:32 -0400, Pittigher, Raymond - ES wrote: > > > > I also used the au tools (aureport, aufind, etc) but just wanting a > > average user to view the bad events brings the need of a point a click > > interface. > > Agreed. > > > The people that now read the audit events for the windows servers are > > spoiled by the cornerbowl tool. I tossed together a little script that > > dumps the audit events into a array, then sorts them and dumps them > > out but the users want a red background for bad and so on. Before I > > went crazy trying to put something together I wanted to see what was > > out in the wild. I guess something that dumps the files into a MySQL > > tables would be the easiest to work with. > > Then what would you use for visualization? > This week I have been thinking about this very thing myself. > Good to know others are as well. > > LCB > > -- > LC (Lenny) Bruzenak > lenny(a)magitekltd.com > The plan would be to rotate the log at midnight Saturday, use the aureport to read the file and give it some kind of format, dump the data into a mysql database, then parse it with php on a apache server with a firefox front end. Or something like that. This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.

14 years, 10 months

2
2
0 / 0

unsubscribe

by Jack Schaible

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

14 years, 10 months

1
0
0 / 0

log files

by Pittigher, Raymond - ES

What do the users of this list use to read the log files? I have tried Spacewalk (which is nice) but is a lot of software to install to read logs. I have looked at Prewikka but do not have it totally configured yet to give it a OK or not. This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.

14 years, 10 months

4
4
0 / 0

audit-2.1.2 released

by Steve Grubb

Hi, I've just released a new version of the audit daemon. It can be downloaded from http://people.redhat.com/sgrubb/audit. It will also be in rawhide soon. The ChangeLog is: - In ausearch/report, fix a segfault caused by MAC_POLICY_LOAD records - In ausearch/report, add and update parsers - In auditd, cleanup DAEMON_ACCEPT and DAEMON_CLOSE addr fields - In ausearch/report, parse addr field of DAEMON_ACCEPT & DAEMON_CLOSE records - In auditd, move startup success to after events are registered - If auditd shutsdown due to failed tcp init, write a DAEMON_ABORT event - Update auditd to avoid the oom killer in new kernels (Andreas Jaeger) - Parse and interpret NETFILTER_PKT events correctly - Return error if auditctl -l fails (#709345) - In audisp-remote, replace glibc's fgets with custom implementation The bulk of this release is fixing up the parsers for new events. This release also updates the oom handler code for recent kernels. And reliability of logging remote events was improved. Please let me know if you run across any problems with this release. -Steve

14 years, 11 months

2
2
0 / 0

[PATCH 2nd revision] Add SELinux context support to AUDIT target

by Mr Dash Four

Add SELinux context support to AUDIT target (2nd revision). Typical (raw auditd) output after applying this patch would be: type=NETFILTER_PKT msg=audit(1305852240.082:31012): action=0 hook=1 len=52 inif=? outif=eth0 saddr=10.1.1.7 daddr=10.1.2.1 ipid=16312 proto=6 sport=56150 dport=22 obj=system_u:object_r:ssh_packet_t:s0 type=NETFILTER_PKT msg=audit(1306772064.079:56): action=0 hook=3 len=48 inif=eth0 outif=? smac=00:05:5d:7c:27:0b dmac=00:02:b3:0a:7f:81 macproto=0x0800 saddr=10.1.2.1 daddr=10.1.1.7 ipid=462 proto=6 sport=3561 dport=22 obj=system_u:object_r:ssh_packet_t:s0 Signed-off-by: Mr Dash Four <mr.dash.four(a)googlemail.com> --- net/netfilter/xt_AUDIT.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/net/netfilter/xt_AUDIT.c b/net/netfilter/xt_AUDIT.c index 363a99e..616cadc 100644 --- a/net/netfilter/xt_AUDIT.c +++ b/net/netfilter/xt_AUDIT.c @@ -20,6 +20,9 @@ #include <linux/netfilter/x_tables.h> #include <linux/netfilter/xt_AUDIT.h> #include <linux/netfilter_bridge/ebtables.h> +#ifdef CONFIG_NF_CONNTRACK_SECMARK +#include <linux/security.h> +#endif #include <net/ipv6.h> #include <net/ip.h> @@ -122,6 +125,10 @@ audit_tg(struct sk_buff *skb, const struct xt_action_param *par) { const struct xt_audit_info *info = par->targinfo; struct audit_buffer *ab; +#ifdef CONFIG_NF_CONNTRACK_SECMARK + u32 len; + char *secctx; +#endif ab = audit_log_start(NULL, GFP_ATOMIC, AUDIT_NETFILTER_PKT); if (ab == NULL) @@ -163,6 +170,14 @@ audit_tg(struct sk_buff *skb, const struct xt_action_param *par) break; } +#ifdef CONFIG_NF_CONNTRACK_SECMARK + if (skb->secmark) + if (!security_secid_to_secctx(skb->secmark, &secctx, &len)) { + audit_log_format(ab, " obj=%s", secctx); + security_release_secctx(secctx, len); + } +#endif + audit_log_end(ab); errout: -- 1.7.3.4

14 years, 11 months

5
28
0 / 0

[v2, PATCH 0/2] MIPS syscall auditing patches

by Ralf Baechle

This is the first cut of the MIPS auditing patches. MIPS doesn't quite fit into the existing pattern of other architectures and I'd appreciate your comments and maybe even an Acked-by for the kernel part so I can feed that upstream. Ralf Changes to v2: The kernel patch went stale due to another conflicting patch of myself and Eric's "Audit: push audit success and retcode into arch ptrace.h" patch. Resolved that conflict.

14 years, 11 months

1
2
0 / 0

Re: Possible regression

by Steve Grubb

On Thursday, June 02, 2011 12:41:41 PM 4javier wrote: > root@Archbox /home/javier $ touch /tmp/test > root@Archbox /home/javier $ cat /tmp/test > root@Archbox /home/javier $ auditctl -w /tmp/test -p wa > root@Archbox /home/javier $ echo ppp >> /tmp/test > root@Archbox /home/javier $ cat /tmp/test > ppp > root@Archbox /home/javier $ ausearch -i -f /tmp/test > <no matches> > root@Archbox /home/javier $ auditctl -l > LIST_RULES: exit,always watch=/tmp/test perm=wa > root@Archbox /home/javier $ echo ppp > /tmp/test > root@Archbox /home/javier $ ausearch -i -f /tmp/test > <no matches> > root@Archbox /home/javier $ ausearch -f /tmp/test > <no matches> > > As you can see from auditcrl -l output, rule seems to be correctly set, but > ausearch doesn't show anything. I duplicated your tests here: [root@localhost ~]# auditctl -w /tmp/test -p wa -k watch [root@localhost ~]# echo "ppp" >> /tmp/test [root@localhost ~]# cat /tmp/test ppp [root@localhost ~]# ausearch --start recent -i -f /tmp/test ---- type=PATH msg=audit(06/02/2011 14:32:45.146:112) : item=0 name=/tmp/test inode=164740 dev=fd:01 mode=file,644 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 type=CWD msg=audit(06/02/2011 14:32:45.146:112) : cwd=/root type=SYSCALL msg=audit(06/02/2011 14:32:45.146:112) : arch=x86_64 syscall=open success=yes exit=3 a0=1842830 a1=441 a2=1b6 a3=0 items=1 ppid=1298 pid=1304 auid=sgrubb uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=bash exe=/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=watch Admittedly I am on the 2.6.38.6 kernel. But I'm not seeing a regression. When you set the perms to "wa" that is only going to be opens for writing or changes to file attributes. So, the cat command will not trigger an event and that is why I only get 1 event. I am also on a 64 bit system, but I would think that didn't matter...unless we have a signed/unsigned comparison problem...what do you have for an inode on the /tmp/watch file? ls -i /tmp/watch should get it. -Steve

14 years, 11 months

2
1
0 / 0

Fwd: Possible regression

by 4javier

---------- Forwarded message ---------- From: 4javier <4javiereg4(a)gmail.com> Date: 2011/6/2 Subject: Re: Possible regression To: Steve Grubb <sgrubb(a)redhat.com> root@Archbox /home/javier $ touch /tmp/test root@Archbox /home/javier $ cat /tmp/test root@Archbox /home/javier $ auditctl -w /tmp/test -p wa root@Archbox /home/javier $ echo ppp >> /tmp/test root@Archbox /home/javier $ cat /tmp/test ppp root@Archbox /home/javier $ ausearch -i -f /tmp/test <no matches> root@Archbox /home/javier $ auditctl -l LIST_RULES: exit,always watch=/tmp/test perm=wa root@Archbox /home/javier $ echo ppp > /tmp/test root@Archbox /home/javier $ ausearch -i -f /tmp/test <no matches> root@Archbox /home/javier $ ausearch -f /tmp/test <no matches> As you can see from auditcrl -l output, rule seems to be correctly set, but ausearch doesn't show anything. 2011/6/2 Steve Grubb <sgrubb(a)redhat.com> > On Thursday, June 02, 2011 09:45:38 AM you wrote: > > you're right...sorry for my fault... > > I didn't use the -a switch. I read the man, but I cannot understand how > > this settings is able to fix the problem with O_CREAT. > > Could you explain that to me, please? > > As far as I know, the problem was fixed in 2006 and there has been no > regression. The - > w command is translated into -a always,exit -F path= under the hood. Its > been this way > since watches were deprecated around 2005/2006. > > How were you testing? You might have found a bug and I just don't know how > to > reproduce it. > > -Steve >

14 years, 11 months

1
0
0 / 0

Re: Possible regression

by Steve Grubb

On Thursday, June 02, 2011 09:45:38 AM you wrote: > you're right...sorry for my fault... > I didn't use the -a switch. I read the man, but I cannot understand how > this settings is able to fix the problem with O_CREAT. > Could you explain that to me, please? As far as I know, the problem was fixed in 2006 and there has been no regression. The - w command is translated into -a always,exit -F path= under the hood. Its been this way since watches were deprecated around 2005/2006. How were you testing? You might have found a bug and I just don't know how to reproduce it. -Steve

14 years, 11 months

1
0
0 / 0

Fwd: Possible regression

by 4javier

---------- Forwarded message ---------- From: 4javier <4javiereg4(a)gmail.com> Date: 2011/6/2 Subject: Re: Possible regression To: Steve Grubb <sgrubb(a)redhat.com> you're right...sorry for my fault... I didn't use the -a switch. I read the man, but I cannot understand how this settings is able to fix the problem with O_CREAT. Could you explain that to me, please? 2011/6/2 Steve Grubb <sgrubb(a)redhat.com> > On Thursday, June 02, 2011 08:48:30 AM 4javier wrote: > > I'm noticing exactly the same problem mentioned into this old message > > http://osdir.com/ml/linux.redhat.security.audit/2006-07/msg00036.html > > Workaround consisting into watching the whole directory containing the > file > > works too. I've found that into 2006 a patch was submitted to solve the > > issue > > http://www.mail-archive.com/linux-audit@redhat.com/msg00476.html > > > > Is this a recent regression, or is there something I don't know? > > I just ran the test from that email and got the following: > > [root@localhost ~]# touch /tmp/test > [root@localhost ~]# auditctl -a always,exit -F path=/tmp/test -F perm=rwa > -k watch > [root@localhost ~]# echo "" > /tmp/test > [root@localhost ~]# cat /tmp/test > > [root@localhost ~]# ausearch --start recent --key watch -i > ---- > type=CONFIG_CHANGE msg=audit(06/02/2011 09:15:49.790:124) : auid=sgrubb > ses=2 > subj=unconfined_u:unconfined_r:auditctl_t:s0-s0:c0.c1023 op="add rule" > key=watch > list=exit res=1 > ---- > type=PATH msg=audit(06/02/2011 09:15:56.970:125) : item=0 name=/tmp/test > inode=164740 > dev=fd:01 mode=file,644 ouid=root ogid=root rdev=00:00 > obj=unconfined_u:object_r:user_tmp_t:s0 > type=CWD msg=audit(06/02/2011 09:15:56.970:125) : cwd=/root > type=SYSCALL msg=audit(06/02/2011 09:15:56.970:125) : arch=x86_64 > syscall=open > success=yes exit=3 a0=28cadd0 a1=241 a2=1b6 a3=0 items=1 ppid=1634 pid=1640 > auid=sgrubb uid=root gid=root euid=root suid=root fsuid=root egid=root > sgid=root > fsgid=root tty=pts1 ses=2 comm=bash exe=/bin/bash > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=watch > ---- > type=PATH msg=audit(06/02/2011 09:16:08.850:126) : item=0 name=/tmp/test > inode=164740 > dev=fd:01 mode=file,644 ouid=root ogid=root rdev=00:00 > obj=unconfined_u:object_r:user_tmp_t:s0 > type=CWD msg=audit(06/02/2011 09:16:08.850:126) : cwd=/root > type=SYSCALL msg=audit(06/02/2011 09:16:08.850:126) : arch=x86_64 > syscall=open > success=yes exit=3 a0=7fffd7a8f943 a1=0 a2=0 a3=32d80819d0 items=1 > ppid=1640 pid=1659 > auid=sgrubb uid=root gid=root euid=root suid=root fsuid=root egid=root > sgid=root > fsgid=root tty=pts1 ses=2 comm=cat exe=/bin/cat > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=watch > [root@localhost ~]# uname -r > 2.6.38.6-26.rc1.fc15.x86_64 > > We have 2 events. Are you getting this? Is something missing? > > -Steve >

14 years, 11 months

1
0
0 / 0

Possible regression

by 4javier

I'm noticing exactly the same problem mentioned into this old message http://osdir.com/ml/linux.redhat.security.audit/2006-07/msg00036.html Workaround consisting into watching the whole directory containing the file works too. I've found that into 2006 a patch was submitted to solve the issue http://www.mail-archive.com/linux-audit@redhat.com/msg00476.html Is this a recent regression, or is there something I don't know? Arch Linux audit 2.1.1 kernel 2.6.38.7 i686 architecture Thanks in advance

14 years, 11 months

2
1
0 / 0

Re: excluding auditd events

by Mr Dash Four

> That would be "user,never". The audit daemon does no filtering. Its in a race with the > kernel to put events to disk before the kernel's backlog overflows. > Yeah, that's it, sorry. Is this backlog configurable (maybe in the same way tcp/udp buffers are via the sysctl daemon)? > The user filter can filter on: pid, uid, gid, auid, and any part of the subject's > selinux label. The only thing not being filtered on that is available is the event's > record type. There are no other attributes available that can be filtered on. > You mean the message type? If so, filtering by selinux label and message type is sufficient, at least for my immediate needs. > It is protected by file permissions. You must be root to write to the file. If you want > to gpg armor your files when you archive them, its possible to script that. Actually, I was thinking more of having a hash against each record (horizontally) and, maybe a separate hash over the current tuple of time:audit count (vertically). It was just an idea and is similar to what I have implemented in my database-based log system (using PostgreSQL) - a token (via smartcard) is taken when the logging starts (at boot up using dracut - I have designed a module for this too) and this token is then used to create a hash when each log/record is inserted into the system and inserts that has as part of the record itself - that prevents tampering with a single record, while a separate hash is kept for a single column across the entire table (timestamp and transaction id in my case) - that prevents tampering entire logs (i.e. adding/deleting entries). > But we've > always taken the position that if someone obtains root privileges, tampering with the > logs is the last thing you need to worry about. I am sure someone said the same thing before SELinux was invented and implemented in Fedora. In SELinux even if you are root you are still restricted by the domain you operate in and by the policies in existence for that particular domain. My view has always been that you can never be too careful and this adds another level of security - an additional barrier for "hackers" to have to break, if you like. >> Finally, another feature which I am badly missing - the ability to see >> audit files loaded remotely by the audit-viewer (audit logs located on >> network shares for example) - this is currently missing and the audit >> viewer bluntly refuses to load audit file if this file is remotely based >> and not on the local file system. Is something planned in that respect to >> enable this? >> > > No idea. > It is a restriction in audit-viewer - at least in the version I am using (stock FC13).

14 years, 11 months

3
11
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Linux-audit June 2011