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, 1 month
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
12 years, 4 months
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
12 years, 4 months
[PATCH] Fix a bug of "autrace -r /bin/ls" in i386
by Peng Haitao
Hello Steve,
When execute "autrace -r /bin/ls" in i386, The error message
"Error inserting audit rule for pid=349" will be outputed.
When execute "ausyscall i386 connect", The error message
"Unknown syscall connect using i386 lookup table" will be outputed.
After apply the patch,
The output of "ausyscall i386 connect" is "socketcall 102".
The output of "autrace -r /bin/ls" should be OK.
Signed-off-by: Peng Haitao <penght(a)cn.fujitsu.com>
---
lib/lookup_table.c | 36 ++++++++++++++++++++++++++++++++++++
tools/ausyscall/ausyscall.c | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/lib/lookup_table.c b/lib/lookup_table.c
index b0abe07..c6f892f 100755
--- a/lib/lookup_table.c
+++ b/lib/lookup_table.c
@@ -29,6 +29,7 @@
#include <stdlib.h>
#include <ctype.h>
#include <errno.h>
+#include <linux/net.h>
#include "libaudit.h"
#include "gen_tables.h"
@@ -96,6 +97,33 @@ const char *audit_field_to_name(int field)
return field_i2s(field);
}
+/* This is the name/value pair used by search tables */
+struct nv_pair {
+ int value;
+ const char *name;
+};
+
+static struct nv_pair socktab[] = {
+ {SYS_SOCKET, "socket"},
+ {SYS_BIND, "bind"},
+ {SYS_CONNECT, "connect"},
+ {SYS_LISTEN, "listen"},
+ {SYS_ACCEPT, "accept"},
+ {SYS_GETSOCKNAME, "getsockname"},
+ {SYS_GETPEERNAME, "getpeername"},
+ {SYS_SOCKETPAIR, "socketpair"},
+ {SYS_SEND, "send"},
+ {SYS_RECV, "recv"},
+ {SYS_SENDTO, "sendto"},
+ {SYS_RECVFROM, "recvfrom"},
+ {SYS_SHUTDOWN, "shutdown"},
+ {SYS_SETSOCKOPT, "setsockopt"},
+ {SYS_GETSOCKOPT, "getsockopt"},
+ {SYS_SENDMSG, "sendmsg"},
+ {SYS_RECVMSG, "recvmsg"}
+};
+#define SOCK_NAMES (sizeof(socktab)/sizeof(socktab[0]))
+
int audit_name_to_syscall(const char *sc, int machine)
{
int res, found;
@@ -104,6 +132,14 @@ int audit_name_to_syscall(const char *sc, int machine)
{
case MACH_X86:
found = i386_syscall_s2i(sc, &res);
+ if (!found) {
+ int i;
+ for(i = 0; i < SOCK_NAMES; i++)
+ if (strcmp(socktab[i].name, sc) == 0) {
+ sc = "socketcall";
+ found = i386_syscall_s2i(sc, &res);
+ }
+ }
break;
case MACH_86_64:
found = x86_64_syscall_s2i(sc, &res);
diff --git a/tools/ausyscall/ausyscall.c b/tools/ausyscall/ausyscall.c
index 565336f..772aa00 100755
--- a/tools/ausyscall/ausyscall.c
+++ b/tools/ausyscall/ausyscall.c
@@ -25,10 +25,38 @@
#include <string.h>
#include <stdlib.h>
#include <ctype.h>
+#include <linux/net.h>
#include "libaudit.h"
#define LAST_SYSCALL 1400 // IA64 is in the 1300's right now
+/* This is the name/value pair used by search tables */
+struct nv_pair {
+ int value;
+ const char *name;
+};
+
+static struct nv_pair socktab[] = {
+ {SYS_SOCKET, "socket"},
+ {SYS_BIND, "bind"},
+ {SYS_CONNECT, "connect"},
+ {SYS_LISTEN, "listen"},
+ {SYS_ACCEPT, "accept"},
+ {SYS_GETSOCKNAME, "getsockname"},
+ {SYS_GETPEERNAME, "getpeername"},
+ {SYS_SOCKETPAIR, "socketpair"},
+ {SYS_SEND, "send"},
+ {SYS_RECV, "recv"},
+ {SYS_SENDTO, "sendto"},
+ {SYS_RECVFROM, "recvfrom"},
+ {SYS_SHUTDOWN, "shutdown"},
+ {SYS_SETSOCKOPT, "setsockopt"},
+ {SYS_GETSOCKOPT, "getsockopt"},
+ {SYS_SENDMSG, "sendmsg"},
+ {SYS_RECVMSG, "recvmsg"}
+};
+#define SOCK_NAMES (sizeof(socktab)/sizeof(socktab[0]))
+
void usage(void)
{
fprintf(stderr, "usage: ausyscall [arch] name | number | --dump | --exact\n");
@@ -119,6 +147,14 @@ int main(int argc, char *argv[])
if (n && strcasestr(n, name)) {
found = 1;
printf("%-18s %d\n", n, i);
+ } else if (n && strcmp(n, "socketcall") == 0) {
+ int j = 0;
+ for (j = 0; j < SOCK_NAMES; j++)
+ if (strcmp(socktab[j].name, name) == 0) {
+ found = 1;
+ printf("%-18s %d\n", n, i);
+ break;
+ }
}
}
if (!found) {
--
1.7.0.1
--
Best Regards,
Peng Haitao
13 years, 10 months
[PATCH] Fix the bug that use option "--session Login-Session-ID" cannot search out all matched logs
by Peng Haitao
Hello Steve,
Use option '--session Login-Session-ID' cannot search out the log which
contains the given Login Session ID and message type is MAC_POLICY_LOAD.
For example:
# echo "type=MAC_POLICY_LOAD msg=audit(1290670949.711:413341): policy loaded auid=0 ses=218" | ausearch --session 218
<no matches>
Signed-off-by: Peng Haitao <penght(a)cn.fujitsu.com>
---
src/ausearch-parse.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/ausearch-parse.c b/src/ausearch-parse.c
index 30a96a2..0ffea14 100755
--- a/src/ausearch-parse.c
+++ b/src/ausearch-parse.c
@@ -1551,14 +1551,14 @@ static int parse_simple_message(const lnode *n, search_items *s)
if (str) {
ptr = str + 4;
term = strchr(ptr, ' ');
- if (term == NULL)
- return 3;
- *term = 0;
+ if (term)
+ *term = 0;
errno = 0;
s->session_id = strtoul(ptr, NULL, 10);
if (errno)
- return 4;
- *term = ' ';
+ return 3;
+ if (term)
+ *term = ' ';
}
}
@@ -1582,7 +1582,7 @@ static int parse_simple_message(const lnode *n, search_items *s)
else // Set it back to something sane
term = str;
} else
- return 5;
+ return 4;
}
}
@@ -1593,7 +1593,7 @@ static int parse_simple_message(const lnode *n, search_items *s)
//create
s->key = malloc(sizeof(slist));
if (s->key == NULL)
- return 6;
+ return 5;
slist_create(s->key);
}
ptr = str + 4;
@@ -1612,7 +1612,7 @@ static int parse_simple_message(const lnode *n, search_items *s)
}
*term = '"';
} else
- return 7;
+ return 6;
} else {
if (s->key) {
char *saved=NULL;
@@ -1652,7 +1652,7 @@ static int parse_simple_message(const lnode *n, search_items *s)
errno = 0;
s->success = strtoul(ptr, NULL, 10);
if (errno)
- return 8;
+ return 7;
if (term)
*term = ' ';
}
--
1.7.0.1
--
Best Regards,
Peng Haitao
13 years, 11 months
[PATCH 0/5] RFC v2: AF_ALG auditing
by Miloslav Trmač
Hello,
these patches add support for auditing uses of the AF_ALG protocol family
developed by Herbert Xu to provide user-space access to kernel crypto
accelerators.
One new record is defined: AUDIT_CRYPTO_USERSPACE_OP. An audited event
is always caused by a syscall, and all other syscall-related data
(process identity, syscall result) is audited in the usual records.
To disable auditing crypto by default and to allow the users to
selectively enable them using filters, a new filter field
AUDIT_CRYPTO_OP is defined; auditing of all crypto operations can
thus be enabled using (auditctl -a exit,always -F crypto_op!=0).
Changes since the previous version:
* Use audit_aux_data instead of a separate linked list
* Don't overwrite initial values of "err" by 0 in algif_skcipher.c
Mirek
Miloslav Trmač (5):
Add general crypto auditing infrastructure
Add unique IDs to AF_ALG sockets
Add "alg_name" operation to af_alg_type.
Audit type-independent events
Audit type-specific crypto operations
crypto/af_alg.c | 110 ++++++++++++++++++++++++++++++++++++++++++++++-
crypto/algif_hash.c | 35 +++++++++++++--
crypto/algif_skcipher.c | 28 +++++++++++-
include/crypto/if_alg.h | 17 +++++--
include/linux/audit.h | 22 +++++++++
kernel/auditfilter.c | 2 +
kernel/auditsc.c | 97 +++++++++++++++++++++++++++++++++++++++++
7 files changed, 296 insertions(+), 15 deletions(-)
--
1.7.3.2
13 years, 11 months
RFC: AF_ALG auditing
by Miloslav Trmac
Hello,
attached is an user-space patch that adds support for auditing uses of the AF_ALG protocol family developed by Herbert Xu to provide user-space access to kernel crypto accelerators. Kernel patches will follow.
One new record is defined: AUDIT_CRYPTO_USERSPACE_OP. An audited event is always caused by a syscall, and all other syscall-related data (process identity, syscall result) is audited in the usual records.
To disable auditing crypto by default and to allow the users to selectively enable them using filters, a new filter field AUDIT_CRYPTO_OP is defined; auditing of all crypto operations can thus be enabled using (auditctl -a exit,always -F crypto_op!=0).
In addition to the user-space patch, attached are also a few example audit entries.
Mirek
13 years, 11 months
reactive audit question
by LC Bruzenak
Steve, others,
I may have asked this before, but it is becoming an issue so I thought
I'd check again anyway.
In our systems there are occasionally AVC "storms" which happen as a
result of some unforeseen (and often unknown) issue tickled by various
reasons.
At fielded sites, we are unable to fix this easily. Since we have to
keep all the audit data, this leads to many problems on a system running
over a weekend, for example, with no administrators around.
I probably need to add in either some rate-limiting code or possibly
kill off the process generating the AVCs. Rate-limiting I'd guess could
go into the auditd. If I wanted to be more brutal and kill the process,
I'd think maybe a modification to the setroubleshoot code would be
workable.
I don't think that a reactive rule is an option -
1) We have our rules locked into the kernel on startup and I'm against
changing that, and
2) maybe "normal" avc counts, under a threshold, we'd still want to see,
from that same process. Besides,
3) unless the rules have been changed, we cannot exclude AVCs from a
particular type/process anyway.
Got any thoughts/ideas/advice?
Thx,
LCB
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
13 years, 11 months
audit a process that disappears
by ESGLinux
Hi All,
I have a problem with a java application that I run on a RHEL machine. The
problem is that the java process dissapears without logging anything,
it´s like anybody outside the process gives a kill to it.
My question is with audit rules I can get any information about what is
happening with this process.
something like this:
-a entry,always -F pid=32179 -S all -k TOMCAT_JAVA
(pid=32179 is the pid of the process)
any idea,
Thanks in advance,
ESG
13 years, 11 months
