7:01 p.m.
Our current audit solution has some problems when a user tries to audit
32bit syscalls on x86_64 systems. (This is a CAPP requirement.)
Most of the problems are due to the fact that there are two unistd.h files
on x86_64 systems.
64bit syscalls are defined in /usr/include/asm-x86_64/unistd.h
32bit syscalls are defined in /usr/include/asm-i386/unistd.h
In these two files, the syscall numbers assigned to syscall names are not
the same.
For example:
From /usr/include/asm-i386/unistd.h:
#define __NR_fork 2
#define __NR_open 5
From /usr/include/asm-x86_64/unistd.h:
#define __NR_open 2
#define __NR_fstat 5
---------------
Problem 1:
"auditctl -t" always translates numbers to name based on
/usr/include/asm-x86_64/unistd.h
(When compiled in 64bit mode on a 64bit system).
Possible Solution 1:
Modify /usr/include/asm-i386/unistd.h and /usr/include/asm-x86_64/unistd.h
so that the 32bit and the 64bit syscall number of any syscall are the same
number.
Possible Solution 2:
Modify auditctl to return both 32bit and 64bit syscall names associated
with that number. This will require a change in how Steve creates his
table.
Example:
auditctl -t 2
Would Return:
32bit: fork
64bit: open
Possible Solution 3:
Modify auditctl -t option to require an additional flag indicating whether
the 32bit or the 64bit syscall number should be returned. Could possibly
use the "-F pers=" flag.
---------------
Problem 2:
"audictl -a" rule also always translates numbers to the syscall name found
in /usr/include/asm-x86_64/unistd.h
Possible Solution 1:
Modify /usr/include/asm-i386/unistd.h and /usr/include/asm-x86_64/unistd.h
so that the 32bit and the 64bit syscall number of any syscall are the same
number.
Possible Solution 2:
auditctl -a <l,a> -S <syscall name> should require additional flag
indicating if 32bit, 64bit, or both syscalls should be audited. Could
possibly use the "pers" flag, assuming personality can determine if a
syscall was compiled 32bit or 64bit.
Then audit rule(s) can be added for the correct syscall number(s).
auditctl -A, and auditctl -d rules would also need to be changed.
---------------
Problem 3:
Personality is currently always 0 by default. We can NOT assume that an
application will manually set personality to another number. Therefore we
cannot currently use the "pers" flag to determine if a syscall was executed
from a 32bit or a 64bit compiled program.
Possible Solution 1:
Modify /usr/include/asm-i386/unistd.h and /usr/include/asm-x86_64/unistd.h
so that the 32bit and the 64bit syscall number of any syscall are the same
number.
Then we would not need to filter on "pers" flag.
Possible Solution 2:
Fix personality so that it determines from the binary whether it was 32bit
or 64bit.
---------------
Problem 4:
Audit record does not indicate if a 32bit or a 64bit syscall was executed.
Because of this, you are unable to determine which syscall resulted in an
audit record.
For example, we cannot currently determine if a record with "syscall=2"
resulted from an __NR_open call (compiled 64bit) or a __NR_fork call
(compiled 32bit) because
From /usr/include/asm-i386/unistd.h:
#define __NR_fork 2
From /usr/include/asm-x86_64/unistd.h:
#define __NR_open 2
Possible Solution 1:
Modify /usr/include/asm-i386/unistd.h and /usr/include/asm-x86_64/unistd.h
so that the 32bit and the 64bit syscall number of any syscall are the same
number.
Possible Solution 2:
Fix 'pers' flag so that it can determine if it was a 32bit or 64bit
syscall. Currently 'pers' flag is included in the audit record if
'pers'!=0.
---------------
Problem 5:
Some syscalls are not defined in either unistd.h file. Therefore, auditctl
-t is not able to translate the syscall number to a syscall name. This is
a usability problem for administrators.
Possible Solution 1:
Add these other syscalls (found in Klaus' syscalltab file, but not in
unistd.h).
Possible Solution 2:
Include an additional header file containing these other syscalls (found in
Klaus' syscalltab file, but not in unistd.h) along with audit, so that
audictl is able to translate those syscall numbers to name.
---------------
I don't know how feasible it is to change the <syscall name> to <syscall
number> mapping so that usr/include/asm-i386/unistd.h and
/usr/include/asm-x86_64/unistd.h are in agreement with each other. But if
it is possible to change this, it could fix several of our problems.
-debbie
7:24 p.m.
* Debora Velarde (dvelarde(a)us.ibm.com) wrote:
Our current audit solution has some problems when a user tries to
audit
32bit syscalls on x86_64 systems. (This is a CAPP requirement.)
Most of the problems are due to the fact that there are two unistd.h files
on x86_64 systems.
64bit syscalls are defined in /usr/include/asm-x86_64/unistd.h
32bit syscalls are defined in /usr/include/asm-i386/unistd.h
In these two files, the syscall numbers assigned to syscall names are not
the same.
For example:
From /usr/include/asm-i386/unistd.h:
#define __NR_fork 2
#define __NR_open 5
From /usr/include/asm-x86_64/unistd.h:
#define __NR_open 2
#define __NR_fstat 5
Yes, we've touched on this a few times on calls.
---------------
Problem 1:
"auditctl -t" always translates numbers to name based on
/usr/include/asm-x86_64/unistd.h
(When compiled in 64bit mode on a 64bit system).
Possible Solution 1:
Modify /usr/include/asm-i386/unistd.h and /usr/include/asm-x86_64/unistd.h
so that the 32bit and the 64bit syscall number of any syscall are the same
number.
This is an absolute no-go. That would _seriously_ break any notion of
binary compatibility. So, the syscall numbers per-arch can't change,
Possible Solution 2:
Modify auditctl to return both 32bit and 64bit syscall names associated
with that number. This will require a change in how Steve creates his
table.
Example:
auditctl -t 2
Would Return:
32bit: fork
64bit: open
Possible Solution 3:
Modify auditctl -t option to require an additional flag indicating whether
the 32bit or the 64bit syscall number should be returned. Could possibly
use the "-F pers=" flag.
This makes most sense.
---------------
Problem 2:
"audictl -a" rule also always translates numbers to the syscall name found
in /usr/include/asm-x86_64/unistd.h
Even with pers flag?
Possible Solution 1:
Modify /usr/include/asm-i386/unistd.h and /usr/include/asm-x86_64/unistd.h
so that the 32bit and the 64bit syscall number of any syscall are the same
number.
Heh, see above.
Possible Solution 2:
auditctl -a <l,a> -S <syscall name> should require additional flag
indicating if 32bit, 64bit, or both syscalls should be audited. Could
possibly use the "pers" flag, assuming personality can determine if a
syscall was compiled 32bit or 64bit.
Then audit rule(s) can be added for the correct syscall number(s).
auditctl -A, and auditctl -d rules would also need to be changed.
---------------
Problem 3:
Personality is currently always 0 by default. We can NOT assume that an
application will manually set personality to another number. Therefore we
cannot currently use the "pers" flag to determine if a syscall was executed
from a 32bit or a 64bit compiled program.
What does this mean? It's the ELF headers that will describe how the
program is treated. What am I missing?
Possible Solution 1:
Modify /usr/include/asm-i386/unistd.h and /usr/include/asm-x86_64/unistd.h
so that the 32bit and the 64bit syscall number of any syscall are the same
number.
> Then we would not need to filter on "pers" flag.
Again, no chance.
Possible Solution 2:
Fix personality so that it determines from the binary whether it was 32bit
or 64bit.
What does this mean?
> ---------------
> Problem 4:
> Audit record does not indicate if a 32bit or a 64bit syscall was executed.
> Because of this, you are unable to determine which syscall resulted in an
> audit record.
> For example, we cannot currently determine if a record with "syscall=2"
> resulted from an __NR_open call (compiled 64bit) or a __NR_fork call
> (compiled 32bit) because
> From /usr/include/asm-i386/unistd.h:
> #define __NR_fork 2
> From /usr/include/asm-x86_64/unistd.h:
> #define __NR_open 2
>
Possible Solution 1:
Modify /usr/include/asm-i386/unistd.h and /usr/include/asm-x86_64/unistd.h
so that the 32bit and the 64bit syscall number of any syscall are the same
number.
Again, no chance.
Possible Solution 2:
Fix 'pers' flag so that it can determine if it was a 32bit or 64bit
syscall. Currently 'pers' flag is included in the audit record if
'pers'!=0.
Is it not legit to assume native binary unless otherwise indicated?
---------------
Problem 5:
Some syscalls are not defined in either unistd.h file. Therefore, auditctl
-t is not able to translate the syscall number to a syscall name. This is
a usability problem for administrators.
Do you have examples?
Possible Solution 1:
Add these other syscalls (found in Klaus' syscalltab file, but not in
unistd.h).
Possible Solution 2:
Include an additional header file containing these other syscalls (found in
Klaus' syscalltab file, but not in unistd.h) along with audit, so that
audictl is able to translate those syscall numbers to name.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
12:04 p.m.
> ---------------
> Problem 2:
> "auditctl -a" rule also always translates numbers to the syscall name
found
> in /usr/include/asm-x86_64/unistd.h
Even with pers flag?
Yes. The current version of auditctl
does.
> ---------------
> Problem 3:
> Personality is currently always 0 by default. We can NOT assume that
an
> application will manually set personality to another number.
Therefore
we
> cannot currently use the "pers" flag to determine if a
syscall was
executed
> from a 32bit or a 64bit compiled program.
What does this mean? It's the ELF headers that will describe how
the
program is treated. What am I missing?
When I brought up this issue it was thought that this could be solved by
filtering on personality.
But personality is always 0 whether my program was compiled in 32bit or 64
bit (unless I set personality to something else inside my program).
Is personality only useful in determining what OS it was compiled on, and
not the mode the program itself was compiled in?
Is it possible to query the ELF headers when the audit record is being
created and add the binary mode (32 or 64) in the audit record?
> Possible Solution 2:
> Fix personality so that it determines from the binary whether it was
32bit
> or 64bit.
What does this mean?
Perhaps it's not personality that
needs to be fixed.
Maybe we need a new 'mode' flag to indicate if the executable compiled was
in 32bit or 64bit mode?
> ---------------
> Problem 4:
> Audit record does not indicate if a 32bit or a 64bit syscall was
executed.
> Because of this, you are unable to determine which syscall
resulted in
an
> audit record.
> For example, we cannot currently determine if a record with "syscall=2"
> resulted from an __NR_open call (compiled 64bit) or a __NR_fork call
> (compiled 32bit) because
> From /usr/include/asm-i386/unistd.h:
> #define __NR_fork 2
> From /usr/include/asm-x86_64/unistd.h:
> #define __NR_open 2
>
> Possible Solution 2:
> Fix 'pers' flag so that it can determine if it was a 32bit or 64bit
> syscall. Currently 'pers' flag is included in the audit record if
> 'pers'!=0.
Is it not legit to assume native binary unless otherwise indicated?
Yes. It is safe to assume that the syscall was compiled on the native OS,
Linux.
But we need to be able to distinguish if it was compiled in 32bit or 64bit
mode.
> ---------------
> Problem 5:
> Some syscalls are not defined in either unistd.h file. Therefore,
auditctl
> -t is not able to translate the syscall number to a syscall
name. This
is
> a usability problem for administrators.
Do you have examples?
OK, looking into this further I found
what I wrote here isn't correct.
All of the syscall numbers that auditctl isn't able to translate are found
in /usr/include/asm-i386/unistd.h.
So once auditctl checks both of the unistd.h files, it shouldn't have a
problem translating any of the syscall numbers.
What isn't found in either of the unistd.h files are some of the syscall
names.
Some of the syscalls in Klaus' list are found in the header files with a
different syscall name.
Here are the ones I found:
Syscall # Klaus /usr/include/asm-i386/unistd.h
182 __NR_chown16 __NR_chown
95 __NR_fchown16 __NR_fchown
16 __NR_lchown16 __NR_lchown
139 __NR_setfsgid16 __NR_setfsgid
138 __NR_setfsuid16 __NR_setfsuid
46 __NR_setgid16 __NR_setgid
81 __NR_setgroups16 __NR_setgroups
71 __NR_setregid16 __NR_setregid
170 __NR_setresgid16 __NR_setresgid
164 __NR_setresuid16 __NR_setresuid
70 __NR_setreuid16 __NR_setreuid
23 __NR_setuid16 __NR_setuid
A user still wouldn't be able to add a filtering rule such as "auditctl -a
entry,always -S chown16", but they could add it by the syscall number or
the name 'chown'.
It is a little strange that in 32bit mode __NR_chown16 = __NR_chown = 182.
But __NR_chown32 = 212. If I added -S chown (running in 32bit mode), I
would of thought that it would be auditing __NR_chown32, not __NR_chown16.
-debbie
12:37 p.m.
On Monday 14 March 2005 13:04, Debora Velarde wrote:
When I brought up this issue it was thought that this could be solved
by
filtering on personality.
I think it sets the personality to 0 - which means LINUX.
But personality is always 0 whether my program was compiled in 32bit
or 64
bit (unless I set personality to something else inside my program).
Is personality only useful in determining what OS it was compiled on, and
not the mode the program itself was compiled in?
Is it possible to query the ELF headers when the audit record is being
created and add the binary mode (32 or 64) in the audit record?
I'll ask around and see if I can find something to help you out. If ld can
figure out what to do, so can we.
But we need to be able to distinguish if it was compiled in 32bit or
64bit
mode.
True, but I still need to do some research on this topic. The whole
personality 64 bit / 32 bit issue is not something I was planning to work on
until after I have the search utility written.
OK, looking into this further I found what I wrote here isn't
correct.
All of the syscall numbers that auditctl isn't able to translate are found
in /usr/include/asm-i386/unistd.h.
The code that generates the table is syscallgen.c. It includes <sys/syscall.h>
which includes <asm/unistd.h>.
So once auditctl checks both of the unistd.h files, it shouldn't
have a
problem translating any of the syscall numbers.
The table is built at compile time. auditctl does not query the files.
What isn't found in either of the unistd.h files are some of the
syscall
names.
Some of the syscalls in Klaus' list are found in the header files with a
different syscall name.
Here are the ones I found:
Syscall # Klaus /usr/include/asm-i386/unistd.h
182 __NR_chown16 __NR_chown
But if you look in the kernel's include file, it is __NR_chown. So where did
the 16 come from? Which name is really valid? The tables have to be
automatically generated or there is way to much room for human error.
A user still wouldn't be able to add a filtering rule such as
"auditctl -a
entry,always -S chown16", but they could add it by the syscall number or
the name 'chown'.
Right. I still wonder about the name. I wonder if strace adds the 16 to it?
It is a little strange that in 32bit mode __NR_chown16 = __NR_chown =
182.
But __NR_chown32 = 212. If I added -S chown (running in 32bit mode), I
would of thought that it would be auditing __NR_chown32, not __NR_chown16.
The 32 refers to the sizeof uid_t. You can have a 32 bit app with a 16 bit
uid_t. What's of interest is what RHEL4 is compiled with for uid_t.
-Steve
1:49 p.m.
> What isn't found in either of the unistd.h files are some of
the
syscall
> names.
> Some of the syscalls in Klaus' list are found in the header files with
a
> different syscall name.
> Here are the ones I found:
> Syscall # Klaus /usr/include/asm-i386/unistd.h
> 182 __NR_chown16 __NR_chown
But if you look in the kernel's include file, it is __NR_chown.
So where
did
the 16 come from? Which name is really valid? The tables have to be
automatically generated or there is way to much room for human error.
I believe Klaus said he got the info in the file he sent me from the kernel
syscall table.
I know he said he used a script to create the file.
2:12 p.m.
On Monday 14 March 2005 14:49, Debora Velarde wrote:
I believe Klaus said he got the info in the file he sent me from the
kernel
syscall table.
I think those are function names, but not the syscall names. For example,
__NR_chown is chown and __NR_chown32 is chown32. What function implements
them is internal to the kernel. User space knows it only by the __NR_
notation.
Hope this helps...
-Steve
2:17 p.m.
On Mon, Mar 14, 2005 at 03:12:26PM -0500, Steve Grubb wrote:
On Monday 14 March 2005 14:49, Debora Velarde wrote:
> I believe Klaus said he got the info in the file he sent me from the kernel
> syscall table.
I think those are function names, but not the syscall names. For example,
__NR_chown is chown and __NR_chown32 is chown32. What function implements
them is internal to the kernel. User space knows it only by the __NR_
notation.
Yes, the data I have was extracted by a script from the kernel syscall
tables and uses the kernel function names as used to build the tables.
There are some differences in the naming scheme but I haven't noticed
anything major other than the numbering schemes and some "old"/"new"
prefix or suffix differences.
The problem with the userspace headers is that they are not always in
sync with the syscalls the kernel actually implements...
-Klaus
2:52 a.m.
* Debora Velarde (dvelarde(a)us.ibm.com) wrote:
> > ---------------
> > Problem 2:
> > "auditctl -a" rule also always translates numbers to the syscall
name
found
> > in /usr/include/asm-x86_64/unistd.h
> Even with pers flag?
Yes. The current version of auditctl does.
OK, that sounds like a small buglet to me.
> > ---------------
> > Problem 3:
> > Personality is currently always 0 by default. We can NOT assume that
an
> > application will manually set personality to another number. Therefore
we
> > cannot currently use the "pers" flag to determine if a syscall was
executed
> > from a 32bit or a 64bit compiled program.
> What does this mean? It's the ELF headers that will describe how the
> program is treated. What am I missing?
When I brought up this issue it was thought that this could be solved by
filtering on personality.
But personality is always 0 whether my program was compiled in 32bit or 64
bit (unless I set personality to something else inside my program).
Hrm, I didn't have this problem. But anyway, if you look at the x86_64
kernel, it looks like you'll get PER_LINUX|READ_IMPLIES_EXEC or simply
PER_LINUX for a 32bit binaries. In either case, this is not useful for
32bit vs. 64bit distinction. However, looking at sparc64 and ia64,
for example, they appear to set PER_LINUX32 for 32-bit ELF programs.
Looks as if this was intentional on x86_64.
Is personality only useful in determining what OS it was compiled on,
and
not the mode the program itself was compiled in?
One issue is, personality can be trivially set from userspace. So, it looks
to be meaningless for audit since the user has ability to change it, w/out
audit being informed, allowing user to potentially dodge audit filters.
Is it possible to query the ELF headers when the audit record is
being
created and add the binary mode (32 or 64) in the audit record?
No, that's not the right method. The kernel knows which mode the binary
is running in. The question, in my mind, is about setting which modes
to care about. E.g. if you say -S open -F uid=500, you want open()
calls to be audited regargdless of mode (otherwise user could use 32bit
app to avoid being audited).
> > Possible Solution 2:
> > Fix personality so that it determines from the binary whether it was
32bit
> > or 64bit.
> What does this mean?
Perhaps it's not personality that needs to be fixed.
Maybe we need a new 'mode' flag to indicate if the executable compiled was
in 32bit or 64bit mode?
Have you tried this on ia64 by any chance?
> > ---------------
> > Problem 4:
> > Audit record does not indicate if a 32bit or a 64bit syscall was
executed.
> > Because of this, you are unable to determine which syscall resulted in
an
> > audit record.
> > For example, we cannot currently determine if a record with
"syscall=2"
> > resulted from an __NR_open call (compiled 64bit) or a __NR_fork call
> > (compiled 32bit) because
> > From /usr/include/asm-i386/unistd.h:
> > #define __NR_fork 2
> > From /usr/include/asm-x86_64/unistd.h:
> > #define __NR_open 2
> >
> > Possible Solution 2:
> > Fix 'pers' flag so that it can determine if it was a 32bit or 64bit
> > syscall. Currently 'pers' flag is included in the audit record if
> > 'pers'!=0.
> Is it not legit to assume native binary unless otherwise indicated?
Yes. It is safe to assume that the syscall was compiled on the native OS,
Linux.
But we need to be able to distinguish if it was compiled in 32bit or 64bit
mode.
Sorry, by native I meant 64bit on a 64bit machine.
> > ---------------
> > Problem 5:
> > Some syscalls are not defined in either unistd.h file. Therefore,
auditctl
> > -t is not able to translate the syscall number to a syscall name. This
is
> > a usability problem for administrators.
> Do you have examples?
OK, looking into this further I found what I wrote here isn't correct.
All of the syscall numbers that auditctl isn't able to translate are found
in /usr/include/asm-i386/unistd.h.
So once auditctl checks both of the unistd.h files, it shouldn't have a
problem translating any of the syscall numbers.
What isn't found in either of the unistd.h files are some of the syscall
names.
Some of the syscalls in Klaus' list are found in the header files with a
different syscall name.
Here are the ones I found:
Syscall # Klaus /usr/include/asm-i386/unistd.h
182 __NR_chown16 __NR_chown
95 __NR_fchown16 __NR_fchown
16 __NR_lchown16 __NR_lchown
139 __NR_setfsgid16 __NR_setfsgid
138 __NR_setfsuid16 __NR_setfsuid
46 __NR_setgid16 __NR_setgid
81 __NR_setgroups16 __NR_setgroups
71 __NR_setregid16 __NR_setregid
170 __NR_setresgid16 __NR_setresgid
164 __NR_setresuid16 __NR_setresuid
70 __NR_setreuid16 __NR_setreuid
23 __NR_setuid16 __NR_setuid
A user still wouldn't be able to add a filtering rule such as "auditctl -a
entry,always -S chown16", but they could add it by the syscall number or
the name 'chown'.
It is a little strange that in 32bit mode __NR_chown16 = __NR_chown = 182.
But __NR_chown32 = 212. If I added -S chown (running in 32bit mode), I
would of thought that it would be auditing __NR_chown32, not __NR_chown16.
Heh, I see. This is an issue of legacy interfaces (like exporting only
16bit uids), not mode (although I wouldn't be surprised if x86_64 64bit
mode didn't even support the old chown16, since its apps are newer,
meaning compiled recently and against newer glibc, and would never pick
up the old legcay interface). Realistically, I'd expect these are
things you'll find rarely, maybe in statically linked old binaries.
It's probably simplest (esp. for admins) to make auditctl aware of these
idiosyncrasies.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
8:59 a.m.
One issue is, personality can be trivially set from userspace. So,
it
looks
to be meaningless for audit since the user has ability to change it,
w/out
audit being informed, allowing user to potentially dodge audit
filters.
Good point.
No, that's not the right method. The kernel knows which mode the
binary
is running in. The question, in my mind, is about setting which modes
to care about. E.g. if you say -S open -F uid=500, you want open()
calls to be audited regargdless of mode (otherwise user could use 32bit
app to avoid being audited).
The other problem is that the audit record doesn't show "syscall=open".
Currently it shows "syscall=2" or "syscall=5", with no mention of
mode.
So if an admin wants to see all audit records for the open syscall, they
have to check all records with either "syscall=2" (open 64bit) or
"syscall=5"(open 32bit). But some of those records could of actually been
generated by 32bit fork (also "syscall=2") or 64bit fstat (also
"syscall=5").
Maybe this is something that can be covered by one of the admin tools.
But the record still needs to mention the mode (at least when it is not
default case)
in order for the admin tool to be able to distinguish between 32bit open
and a 64bit fstat (both syscall=5).
Have you tried this on ia64 by any chance?
No. We don't
have an ia64 system yet. Once we do, I will try it.
> > Is it not legit to assume native binary unless otherwise
indicated?
> Yes. It is safe to assume that the syscall was compiled on the native
OS,
> Linux.
> But we need to be able to distinguish if it was compiled in 32bit or
64bit
> mode.
Sorry, by native I meant 64bit on a 64bit machine.
We could
assume if not indicated then the default would be 64bit on a 64bit
system.
But we need a way to indicate that it is not the default case.
Heh, I see. This is an issue of legacy interfaces (like exporting
only
16bit uids), not mode (although I wouldn't be surprised if x86_64 64bit
mode didn't even support the old chown16, since its apps are newer,
meaning compiled recently and against newer glibc, and would never pick
up the old legcay interface). Realistically, I'd expect these are
things you'll find rarely, maybe in statically linked old binaries.
It's probably simplest (esp. for admins) to make auditctl aware of these
idiosyncrasies.
Maybe this is more of a "nice to have" item.
7:55 a.m.
On Tue, Mar 15, 2005 at 12:52:17AM -0800, Chris Wright wrote:
Have you tried this on ia64 by any chance?
We are doing some audit testing on ia64 at HP and will try this out.
I am currently looking into a panic that occurs when syscall auditing
is enabled. I hope to have more information to post soon.
Amy
12:01 p.m.
* Amy Griffis (amy.griffis(a)hp.com) wrote:
On Tue, Mar 15, 2005 at 12:52:17AM -0800, Chris Wright wrote:
> Have you tried this on ia64 by any chance?
We are doing some audit testing on ia64 at HP and will try this out.
I am currently looking into a panic that occurs when syscall auditing
is enabled. I hope to have more information to post soon.
Ooh, information much appreciated. Thanks for testing.
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
7220
days inactive
7224
days old
linux-audit@lists.linux-audit.osci.io
10 comments
5 participants
participants (5)
-
Amy Griffis -
Chris Wright -
Debora Velarde -
Klaus Weidner -
Steve Grubb