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, 3 months
linux-audit: reconstruct path names from syscall events?
by John Feuerstein
Hi,
I would like to audit all changes to a directory tree using the linux
auditing system[1].
# auditctl -a exit,always -F dir=/etc/ -F perm=wa
It seems like the GNU coreutils are enough to break the audit trail.
The resulting SYSCALL events provide CWD and multiple PATH records,
depending on the syscall. If one of the PATH records is relative, I can
reconstruct the absolute path using the CWD record.
However, that does not work for the whole *at syscall family
(unlinkat(2), renameat(2), linkat(2), ...); accepting paths relative to
a given directory file descriptor. GNU coreutils are prominent users,
for example "rm -r" making use of unlinkat(2) to prevent races.
Things like dup(2) and fd passing via unix domain sockets come to mind.
It's the same old story again: mapping fds to path names is ambiguous at
best, if not impossible.
I wonder why such incomplete file system auditing rules are considered
sufficient in the CAPP/LSPP/NISPOM/STIG rulesets?
Here's a simplified example:
$ cd /tmp
$ mkdir dir
$ touch dir/file
$ ls -ldi /tmp /tmp/dir /tmp/dir/file
2057 drwxrwxrwt 9 root root 380 Sep 17 00:02 /tmp
58781 drwxr-xr-x 2 john john 40 Sep 17 00:02 /tmp/dir
56228 -rw-r--r-- 1 john john 0 Sep 17 00:02 /tmp/dir/file
$ cat > unlinkat.c
#include <unistd.h>
#include <fcntl.h>
int main(int argc, char **argv)
{
int dirfd = open("dir", O_RDONLY);
unlinkat(dirfd, "file", 0);
return 0;
}
^D
$ make unlinkat
cc unlinkat.c -o unlinkat
$ sudo autrace ./unlinkat
Waiting to execute: ./unlinkat
Cleaning up...
Trace complete. You can locate the records with 'ausearch -i -p 32121'
$ ls -li dir
total 0
Now, looking at the resulting raw SYSCALL event for unlinkat(2):
type=SYSCALL msg=audit(1316210542.899:779): arch=c000003e syscall=263 success=yes exit=0 a0=3 a1=400690 a2=0 a3=0 items=2 ppid=32106 pid=32121 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts12 ses=36 comm="unlinkat" exe="/tmp/unlinkat" key=(null)
type=CWD msg=audit(1316210542.899:779): cwd="/tmp"
type=PATH msg=audit(1316210542.899:779): item=0 name="/tmp" inode=58781 dev=00:0e mode=040755 ouid=1000 ogid=1000 rdev=00:00
type=PATH msg=audit(1316210542.899:779): item=1 name="file" inode=56228 dev=00:0e mode=0100644 ouid=1000 ogid=1000 rdev=00:00
type=EOE msg=audit(1316210542.899:779):
- From this event alone, there's no way to answer "Who unlinked
/tmp/dir/file?". For what it's worth, the provided path names would be
exactly the same if we had unlinked "/tmp/dir/dir/dir/dir/dir/file".
- PATH item 0 reports the inode of "/tmp/dir" (58781, see ls output
above), however, the reported path name is "/tmp" (bug?).
In this example I've used autrace, which traces everything, so I could
possibly search for a previous open(2) of inode 58781. And indeed, there
it is:
type=SYSCALL msg=audit(1316210542.899:778): arch=c000003e syscall=2 success=yes exit=3 a0=40068c a1=0 a2=7fff22724fc8 a3=0 items=1 ppid=32106 pid=32121 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts12 ses=36 comm="unlinkat" exe="/tmp/unlinkat" key=(null)
type=CWD msg=audit(1316210542.899:778): cwd="/tmp"
type=PATH msg=audit(1316210542.899:778): item=0 name="dir" inode=58781 dev=00:0e mode=040755 ouid=1000 ogid=1000 rdev=00:00
type=EOE msg=audit(1316210542.899:778):
Great, so inode 58781 was opened using "/tmp/dir", and therefore, the relative
path "file" given to unlinkat(2) above could possibly translate to
"/tmp/dir/path"... not really feeling confident here.
- All file system auditing rules in various rulesets and the examples in
the documentation add the "-F perm=wa" (or similar) filter, so the
open(2) wouldn't even make it into the audit trail.
- If you can handle the volume and log all open(2), what happens if the
open(2) was done hours, days, weeks, ... ago?
- What if the open(2) was done by another process which passed the fd
on a unix domain socket?
It looks like the kernel auditing code should provide
... item=0 name="/tmp/dir" inode=58781 ...
in the unlinkat(2) syscall event above. Looking up the unlinkat(2)
documentation:
int unlinkat(int dirfd, const char *pathname, int flags);
If the pathname given in pathname is relative, then it is
interpreted relative to the directory referred to by the file
descriptor dirfd (rather than relative to the current working
directory of the calling process, as is done by unlink(2) and
rmdir(2) for a relative pathname).
If the pathname given in pathname is relative and dirfd is the
special value AT_FDCWD, then pathname is interpreted relative
to the current working directory of the calling process (like
unlink(2) and rmdir(2)).
As you might see, there's not only the fd->pathname problem, but
also the special case for AT_FDCWD. In this case the kernel side should
probably just duplicate CWD's path name into item 0's path name. But
that's just unlinkat(2), there are a lot more.
What am I missing here? Is there no way to audit a directory tree?
I've looked at alternatives: Inotify watches won't scale to big trees
and events lack so much detail that they can't be used for auditing.
Fanotify, while providing the pid, still lacks a lot of events and
passes fds; the example code relies on readlink("/proc/self/fd/...").
Thanks,
John
[1] http://people.redhat.com/sgrubb/audit/
--
John Feuerstein <john(a)feurix.com>
12 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, 6 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, 6 months
Kernel oops+crash on repeated auditd restarts
by Valentin Avram
Hello.
Did anybody ever experience kernel oopses and even kernel crashes (after a
while), by just restarting repeatedly the auditd daemon?
I ask this because i had this problem on Dell R610 servers running Gentoo
Linux kernels gentoo-sources-3.0.6 and gentoo-sources-2.6.37-r4 (see this
bug: https://bugs.gentoo.org/show_bug.cgi?id=389405 ).
The kernels are nothing special, just the vanilla 2.6.37 and 3.0.6 with a
few gentoo patches (see https://lkml.org/lkml/2011/11/28/330 ).
The auditd version is 2.1.3 (latest). The audit.rules file contains
basically the following rules:
-D
-w /etc -p wa -k etc-directory
[snip: same for /sbin, /bin, /usr/sbin, /usr/bin]
-a exit,never -F dir=/lib/rc -k skip-lib-rc
-w /lib -p wa -k lib-directory
-w /usr/lib -p wa -k usr-lib-directory
-a exit,never -F arch=b32 -S read [snip: -S for write,open,fstat,mmap etc.]
-k excluded-syscalls
-b 8192
The bug seems to be somewhere in the fsnotify kernel part, however Gentoo
kernel devs and ppl on lkml did not seem too interested, so.. did anybody
notice a similar behaviour? Or better yet, is anybody willing to run on one
of your servers this simple test: start the minimum server services, use a
similar audit.rules configuration, then start auditd and run in a shell the
following one-liner:
while :; do /etc/init.d/auditd stop ; sleep 5 ; /etc/init.d/auditd start ;
sleep 5 ; done
This was enough to oops and crash the kernel in less than one hour on the
servers where i did the tests. If any similar behavior happens, i'd be very
interested to know the the kernel version and distro.
Thank you for your time.
12 years, 8 months
[PATCH] auparse: apparmor fields
by Marcelo Cerri
Hi,
I'm taking a look at the AVC records generated by apparmor and some fields in
these records, such as "apparmor" and "operation", are quoted and are not listed
in the auparse/typetab.h file.
Searching in the kernel source, I've found the piece of code that generates the
AVC records and I noticed that it uses the function audit_log_string, which
just add quotes to the string, instead of audit_log_untrustedstring, which seems
to be targeted to escaped fields.
I'd like to know if these fields should be treated the same way as escaped
fields by libauparse or maybe it should be changed in the kernel.
If libauparse really needs to be changed, please consider this patch that
includes the fields "apparmor" and "operation" in the file auparse/typetab.h as
escaped fields.
Regards,
Marcelo
---
auparse/typetab.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/auparse/typetab.h b/auparse/typetab.h
index 7838c17..0a81e25 100644
--- a/auparse/typetab.h
+++ b/auparse/typetab.h
@@ -86,3 +86,5 @@ _S(AUPARSE_TYPE_NFPROTO, "family" )
_S(AUPARSE_TYPE_ICMPTYPE, "icmptype" )
_S(AUPARSE_TYPE_PROTOCOL, "proto" )
_S(AUPARSE_TYPE_ADDR, "addr" )
+_S(AUPARSE_TYPE_ESCAPED, "apparmor" )
+_S(AUPARSE_TYPE_ESCAPED, "operation" )
--
1.7.1
12 years, 9 months
New audit package release this week
by Steve Grubb
Hello,
Just wanted to let anyone testing the svn code know that I will be releasing a
new audit package this week (probably Thursday). Please let me know if there are
any bug fixes that need to get into svn for the next release.
Thanks,
-Steve
12 years, 9 months
[PATCH 0/2] Improvements to AVC record matching
by Marcelo Cerri
This set of patches is intended to improve how auvirt matches AVC records.
Currently, auvirt just matches AVC records generated by SELinux that have a
guest context as target context.
With the first patch, auvirt will also match records that have a guest context
as source context, which means that denied actions performed by a guest will
also be matched.
The second patch adds similar support for AVC records generated by AppArmor.
With this patch, auvirt will match AVC records generated due to an AppArmor
profile generated by libvirt to a guest. It will also match AVC records which
the target is one of the resources assigned to a guest.
Marcelo Cerri (2):
auvirt: Improve matching of AVC records generated by SELinux
auvirt: Add support for AVC records generated by AppArmor
tools/auvirt/auvirt.c | 276 +++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 256 insertions(+), 20 deletions(-)
12 years, 9 months
test patch for auditctl inter-field comparisons on euid/uid, egid/gid
by Peter Moody
This patch extends Eric's test patch from 11/17 (
http://www.redhat.com/archives/linux-audit/2011-November/msg00045.html).
This turns -C into a long opt with similar syntax to -F.
This allows uid/euid and gid/egid to be compared, like
auditctl -a exit,always -F arch=b64 -C 'euid!=uid' -S execve -F 'euid!=0'
-F 'success=1'
which would audit on someone executing a setuid binary if the binary isn't
setuid root.
You can also check for writes to overly permissive files like
auditctl -a exit,always -F arch=b64 -C 'obj_uid!=uid' -F 'uid!=0' -F
'dir=/home/' -F 'success=1' -S open -F 'a2&=2'
This functionality is helpful in detecting user compromises across a shared
fleet; eg, attacker finds a world-writable shell script
(/home/victim/.bashrc, it's happened...) and inserts "cp /bin/bash /tmp/;
chmod 7777 /tmp/bash". After victim executes this, attacker executes
/tmp/bash -p and becomes victim.
One strange thing related to this patch: auditd seems to be reporting
success for a normal user process (gklrellm) opening /proc/meminfo (mode
444) O_RDWR, and I don't see how this is possible. eg:
type=SYSCALL msg=audit(1323540255.146:97): arch=c000003e syscall=2
success=yes exit=13 a0=4b1972 a1=0 a2=1b6 a3=0 items=1 ppid=1704 pid=1797
auid=11532 uid=11532 gid=5000 euid=11532 suid=11532 fsuid=11532 egid=5000
sgid=5000 fsgid=5000 tty=(none) ses=1 comm="gkrellm" exe="/usr/bin/gkrellm"
key="permissive"
type=CWD msg=audit(1323540255.146:97): cwd="/home/pmoody"
type=PATH msg=audit(1323540255.146:97): item=0 name="/proc/meminfo" inode=
4026532008 dev=00:03 mode=0100444 ouid=0 ogid=0 rdev=00:00
hopefully someone with more auditd internal knowledge can explain what's
going on.
auditctl -l doesn't know how to report this yet; if this patch is generally
acceptable, I can try to fix that and update the manpage, etc.
Signed-off-by: Peter Moody <pmoody(a)google.com>
---
trunk/auparse/typetab.h | 1 +
trunk/lib/fieldtab.h | 1 +
trunk/lib/libaudit.c | 144
+++++++++++++++++++++++++++++++++++++++++++
trunk/lib/libaudit.h | 2 +
trunk/src/auditctl.c | 19 +++++-
trunk/src/ausearch-report.c | 1 +
6 files changed, 166 insertions(+), 2 deletions(-)
diff --git a/trunk/auparse/typetab.h b/trunk/auparse/typetab.h
index 746573c..3e6c6d1 100644
--- a/trunk/auparse/typetab.h
+++ b/trunk/auparse/typetab.h
@@ -32,6 +32,7 @@ _S(AUPARSE_TYPE_UID, "iuid" )
_S(AUPARSE_TYPE_UID, "id" )
_S(AUPARSE_TYPE_UID, "inode_uid" )
_S(AUPARSE_TYPE_UID, "sauid" )
+_S(AUPARSE_TYPE_UID, "obj_uid" )
_S(AUPARSE_TYPE_GID, "gid" )
_S(AUPARSE_TYPE_GID, "egid" )
_S(AUPARSE_TYPE_GID, "sgid" )
diff --git a/trunk/lib/fieldtab.h b/trunk/lib/fieldtab.h
index ad95814..e053df6 100644
--- a/trunk/lib/fieldtab.h
+++ b/trunk/lib/fieldtab.h
@@ -55,6 +55,7 @@ _S(AUDIT_WATCH, "path" )
_S(AUDIT_PERM, "perm" )
_S(AUDIT_DIR, "dir" )
_S(AUDIT_FILETYPE, "filetype" )
+_S(AUDIT_OBJ_UID, "obj_uid" )
_S(AUDIT_ARG0, "a0" )
_S(AUDIT_ARG1, "a1" )
diff --git a/trunk/lib/libaudit.c b/trunk/lib/libaudit.c
index 9a5070c..b10f984 100644
--- a/trunk/lib/libaudit.c
+++ b/trunk/lib/libaudit.c
@@ -783,6 +783,148 @@ int audit_rule_syscallbyname_data(struct
audit_rule_data *rule,
}
hidden_def(audit_rule_syscallbyname_data)
+int audit_rule_interfield_fieldpair_data(struct audit_rule_data **rulep,
+ const char *pair,
+ int flags) {
+ const char *f = pair;
+ char *v;
+ int op;
+ int field1, field2;
+ int vlen;
+ int offset;
+ struct audit_rule_data *rule = *rulep;
+
+ if (f == NULL)
+ return -1;
+
+ /* look for 2-char operators first
+ then look for 1-char operators afterwards
+ when found, null out the bytes under the operators to split
+ and set value pointer just past operator bytes
+ */
+ if ( (v = strstr(pair, "!=")) ) {
+ *v++ = '\0';
+ *v++ = '\0';
+ op = AUDIT_NOT_EQUAL;
+ } else if ( (v = strstr(pair, "=")) ) {
+ *v++ = '\0';
+ op = AUDIT_EQUAL;
+ } else {
+ fprintf(stderr, "only =, != comparisons are allowed in interfield\n");
+ return -1;
+ }
+
+ if (v == NULL)
+ return -1;
+
+ if (*f == 0)
+ return -22;
+
+ if (*v == 0)
+ return -20;
+
+ if ((field1 = audit_name_to_field(f)) < 0)
+ return -2;
+
+ if ((field2 = audit_name_to_field(v)) < 0)
+ return -2;
+
+ /* Exclude filter can be used only with MSGTYPE field */
+ if (flags == AUDIT_FILTER_EXCLUDE && field1 != AUDIT_MSGTYPE)
+ return -12;
+
+ // It should always be AUDIT_FIELD_COMPARE
+ rule->fields[rule->field_count] = AUDIT_FIELD_COMPARE;
+ rule->fieldflags[rule->field_count] = op;
+ switch (field1)
+ {
+ case AUDIT_UID:
+ switch(field2) {
+ case AUDIT_EUID:
+ rule->values[rule->field_count] = AUDIT_COMPARE_UID_TO_EUID;
+ break;
+ case AUDIT_OBJ_UID:
+ rule->values[rule->field_count] = AUDIT_COMPARE_UID_TO_OBJ_UID;
+ break;
+ default:
+ return -1;
+ }
+ break;
+ case AUDIT_EUID:
+ switch(field2) {
+ case AUDIT_UID:
+ rule->values[rule->field_count] = AUDIT_COMPARE_UID_TO_EUID;
+ break;
+ default:
+ return -1;
+ }
+ break;
+ case AUDIT_OBJ_UID:
+ switch(field2) {
+ case AUDIT_UID:
+ rule->values[rule->field_count] = AUDIT_COMPARE_UID_TO_OBJ_UID;
+ break;
+ default:
+ return -1;
+ }
+ break;
+ case AUDIT_OBJ_GID:
+ switch(field2) {
+ case AUDIT_GID:
+ rule->values[rule->field_count] = AUDIT_COMPARE_GID_TO_OBJ_GID;
+ break;
+ default:
+ return -1;
+ }
+ break;
+ case AUDIT_GID:
+ switch(field2) {
+ case AUDIT_EGID:
+ rule->values[rule->field_count] = AUDIT_COMPARE_GID_TO_EGID;
+ break;
+ case AUDIT_OBJ_GID:
+ rule->values[rule->field_count] = AUDIT_COMPARE_GID_TO_OBJ_GID;
+ break;
+ default:
+ return -1;
+ }
+ break;
+ case AUDIT_EGID:
+ switch(field2) {
+ case AUDIT_OBJ_GID:
+ rule->values[rule->field_count] = AUDIT_COMPARE_GID_TO_EGID;
+ break;
+ default:
+ return -1;
+ }
+ break;
+ /* fallthrough */
+ default:
+ if (field1 == AUDIT_INODE) {
+ if (!(op == AUDIT_NOT_EQUAL ||
+ op == AUDIT_EQUAL))
+ return -13;
+ }
+
+ if (field1 == AUDIT_PPID && !(flags == AUDIT_FILTER_EXIT
+ || flags == AUDIT_FILTER_ENTRY))
+ return -17;
+
+ if (!isdigit((char)*(v)))
+ return -21;
+
+ if (field1 == AUDIT_INODE)
+ rule->values[rule->field_count] =
+ strtoul(v, NULL, 0);
+ else
+ rule->values[rule->field_count] =
+ strtol(v, NULL, 0);
+ break;
+ }
+ rule->field_count++;
+ return 0;
+}
+
int audit_rule_fieldpair_data(struct audit_rule_data **rulep, const char
*pair,
int flags)
{
@@ -857,6 +999,8 @@ int audit_rule_fieldpair_data(struct audit_rule_data
**rulep, const char *pair,
case AUDIT_SUID:
case AUDIT_FSUID:
case AUDIT_LOGINUID:
+ case AUDIT_OBJ_UID:
+ case AUDIT_OBJ_GID:
// Do positive & negative separate for 32 bit systems
vlen = strlen(v);
if (isdigit((char)*(v)))
diff --git a/trunk/lib/libaudit.h b/trunk/lib/libaudit.h
index 8feaa39..911bce4 100644
--- a/trunk/lib/libaudit.h
+++ b/trunk/lib/libaudit.h
@@ -428,6 +428,8 @@ extern int audit_rule_syscallbyname_data(struct
audit_rule_data *rule,
* adding new fields */
extern int audit_rule_fieldpair_data(struct audit_rule_data **rulep,
const char *pair, int flags);
+extern int audit_rule_interfield_fieldpair_data(struct audit_rule_data
**rulep,
+ const char *pair, int flags);
extern void audit_rule_free_data(struct audit_rule_data *rule);
#ifdef __cplusplus
diff --git a/trunk/src/auditctl.c b/trunk/src/auditctl.c
index 34b7935..d7ec998 100644
--- a/trunk/src/auditctl.c
+++ b/trunk/src/auditctl.c
@@ -482,7 +482,7 @@ static int setopt(int count, int lineno, char *vars[])
keylen = AUDIT_MAX_KEY_LEN;
while ((retval >= 0) && (c = getopt(count, vars,
- "hislDvte:f:r:b:a:A:d:S:F:m:R:w:W:k:p:q:")) != EOF) {
+ "hislDvtC:e:f:r:b:a:A:d:S:F:m:R:w:W:k:p:q:")) != EOF) {
int flags = AUDIT_FILTER_UNSET;
rc = 10; // Init to something impossible to see if unused.
switch (c) {
@@ -731,7 +731,6 @@ static int setopt(int count, int lineno, char *vars[])
retval = -1;
break;
}
-
rc = audit_rule_fieldpair_data(&rule_new,optarg,flags);
if (rc != 0) {
audit_number_to_errmsg(rc, optarg);
@@ -743,6 +742,22 @@ static int setopt(int count, int lineno, char *vars[])
}
break;
+ case 'C':
+ if (add != AUDIT_FILTER_UNSET)
+ flags = add & AUDIT_FILTER_MASK;
+ else if (del != AUDIT_FILTER_UNSET)
+ flags = del & AUDIT_FILTER_MASK;
+
+ rc = audit_rule_interfield_fieldpair_data(&rule_new, optarg, flags);
+ if (rc != 0) {
+ audit_number_to_errmsg(rc, optarg);
+ retval = -1;
+ } else {
+ if (rule_new->fields[rule_new->field_count - 1] ==
+ AUDIT_PERM)
+ audit_permadded = 1;
+ }
+ break;
case 'm':
if (count > 3) {
fprintf(stderr,
diff --git a/trunk/src/ausearch-report.c b/trunk/src/ausearch-report.c
index d50c732..62e1ae0 100644
--- a/trunk/src/ausearch-report.c
+++ b/trunk/src/ausearch-report.c
@@ -333,6 +333,7 @@ static struct nv_pair typetab[] = {
{T_UID, "id"},
{T_UID, "inode_uid"},
{T_UID, "sauid"},
+ {T_UID, "obj_uid"},
{T_GID, "gid"},
{T_GID, "egid"},
{T_GID, "sgid"},
--
1.7.3.1
--
Peter Moody Google 1.650.253.7306
Security Engineer pgp:0xC3410038
12 years, 9 months
Re: [PATCH - linux-next] ARM: ptrace: Fix audit caused compile error
by Eric Paris
On Tue, 2012-02-21 at 13:30 +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 21, 2012 at 01:16:17PM +0000, Will Deacon wrote:
> > On Tue, Feb 21, 2012 at 12:04:15PM +0000, Peter Ujfalusi wrote:
> > > While trying to compile the kernel for ARM (omap2plus_defconfig) the kernel
> > > build fails with:
> > >
> > > arch/arm/kernel/ptrace.c: In function ‘syscall_trace’:
> > > arch/arm/kernel/ptrace.c:920:3: error: implicit declaration of function ‘audit_syscall_exit’
> > > arch/arm/kernel/ptrace.c:922:3: error: implicit declaration of function ‘audit_syscall_entry’
> > > arch/arm/kernel/ptrace.c:922:23: error: ‘AUDIT_ARCH_ARMEB’ undeclared (first use in this function)
> > > arch/arm/kernel/ptrace.c:922:23: note: each undeclared identifier is reported only once for each function it appears in
> > > make[1]: *** [arch/arm/kernel/ptrace.o] Error 1
> > >
> > > The issue created by commit:
> > > 29ef73b7 Kernel: Audit Support For The ARM Platform
> > >
> > > We need to include the linux/audit.h header to the arch/arm/kernel/ptrace.c
> > > file to be able to compile the kernel.
> >
> > This was already reported and I think Russell was going to revert the
> > offending commit, since it needed some rework to handle little-endian
> > configurations.
> >
> > I can't see the revert in any of the trees I'm tracking though...
>
> I never pushed that out because I thought someone was going to fix it.
> Were any patches produced to fix it? I can't see anything in the patch
> system and I couldn't see anything on the list.
>
> It seems the previous thread about it just died. Oh well, I guess a
> revert is what's required after all.
http://marc.info/?l=linux-arm-kernel&m=132928424120369&w=2
???
12 years, 10 months
