11:20 a.m.
Here is a sample test to syscall filtering on personality:
Use the Makefile to create the 64bit version and the 32bit version of the
test.
Execute 'pers64'. See new audit record in /var/log/audit.log.
Execute 'pers32'. No new audit records in /var/log/audit.log.
(chmod is syscall 90)
(See attached file: pers64.c)
(See attached file: pers32.c)
(See attached file: Makefile)
-debbie
6:46 p.m.
New subject: syscall filtering on personality
On Wednesday 02 March 2005 12:20, Debora Velarde wrote:
Here is a sample test to syscall filtering on personality:
Not sure what is going on. I think this is an area that Chris or David can
help us with. I never got your program to work. I never got anything to
trigger on chmod for that matter. So, I modified your program to use "open"
since I know that one produced data.
When I set pers=0 - the Linux default, I never got a hit. But, if I changed
the pers to 8 and set 8 for the personality in the program I got data:
Mar 2 19:35:59 localhost kernel: audit(1109810159.968:6933803): syscall=5
per=8 exit=3 a0=80485e1 a1=0 a2=bfe26ef8 a3=bfe26f9c items=1 pid=3518
loginuid=4325 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
Mar 2 19:35:59 localhost kernel: audit(1109810159.968:6933803): item=0
name=/tmp/pers32_check inode=21 dev=03:08 mode=0100644 uid=0 gid=0 rdev=00:00
This is what the program looks like:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/fcntl.h>
#include <sys/personality.h>
int main()
{
/* touch temp file */
system("rm -f /tmp/pers32_check");
system("touch /tmp/pers32_check");
/* setup filtering rule */
system("/sbin/auditctl -D");
system("/sbin/auditctl -a entry,always -S open -F pers=0x08");
/* execute open syscall */
personality(0x08);
open("/tmp/pers32_check", O_RDONLY);
printf("Personality: %ld\n", personality(0xffffffff));
return 0;
}
-Steve
2:18 p.m.
New subject: syscall filtering on personality
When I compile Steve's program in 64bit mode on a 64bit system, I do get an
audit record in /var/log/messages:
Mar 8 19:20:42 opteron2 kernel: audit(1110331242.815:4907733): syscall=2
per=8 exit=3 a0=40077d a1=0 a2=0 a3=7fbffffb01 items=1 pid=10917
loginuid=-1 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
Mar 8 19:20:42 opteron2 kernel: audit(1110331242.815:4907733): item=0
name=/tmp/pers32_check inode=210521 dev=00:00
But when I compile it in 32bit mode on a 64bit system, I do not get any
audit records.
The reason why is because we are using "-S open" in the filter rule. This
is adding syscall 2, because in /usr/include/asm-x86_64/unistd.h, __NR_open
= 2.
However, in /usr/include/asm-i386/unistd.h, __NR_open=5. But even if I
compile the test case in 32bit mode, it is only auditing syscall 2 and
ignores syscall 5.
If I replace one line in the test,
< system("/sbin/auditctl -a entry,always -S open -F pers=0x08");
With
system("/sbin/auditctl -a entry,always -S 2 -F
pers=0x08");
system("/sbin/auditctl -a entry,always -S 5 -F pers=0x08");
So I
am now auditing both syscall numbers 2 and 5,
When I compile and run in 64bit mode, I see the audit record with
syscall=2:
Mar 8 19:27:57 opteron2 kernel: audit(1110331677.999:4913222): syscall=2
per=8 exit=3 a0=4007e4 a1=0 a2=3e1d82e5e0 a3=7fbffffb01 items=1 pid=10929
loginuid=-1 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
Mar 8 19:27:57 opteron2 kernel: audit(1110331677.999:4913222): item=0
name=/tmp/pers32_check inode=210521 dev=00:00
And when I compile and run in 32bit mode, I see the audit record with
syscall=5:
Mar 8 19:28:31 opteron2 kernel: audit(1110331711.190:4915074): syscall=5
per=8 exit=3 a0=ffffdd40 a1=ffffddb4 a2=8049690 a3=0 items=1 pid=10938
loginuid=-1 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
Mar 8 19:28:31 opteron2 kernel: audit(1110331711.190:4915074): item=0
name=/tmp/pers32_check inode=210521 dev=00:00
So it looks like, if you add a syscall by name to auditctl, it always adds
only the rule for the 64bit syscall number. Should auditctl add both? Or
should auditctl use the pers flag to figure out which syscall number to
add?
-debbie
linux-audit-bounces(a)redhat.com wrote on 03/02/2005 06:46:01 PM:
On Wednesday 02 March 2005 12:20, Debora Velarde wrote:
> Here is a sample test to syscall filtering on personality:
Not sure what is going on. I think this is an area that Chris or
David
can
help us with. I never got your program to work. I never got anything
to
trigger on chmod for that matter. So, I modified your program to use
"open"
since I know that one produced data.
When I set pers=0 - the Linux default, I never got a hit. But, if I
changed
the pers to 8 and set 8 for the personality in the program I got
data:
Mar 2 19:35:59 localhost kernel: audit(1109810159.968:6933803):
syscall=5
per=8 exit=3 a0=80485e1 a1=0 a2=bfe26ef8 a3=bfe26f9c items=1
pid=3518
loginuid=4325 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
Mar 2 19:35:59 localhost kernel: audit(1109810159.968:6933803): item=0
name=/tmp/pers32_check inode=21 dev=03:08 mode=0100644 uid=0 gid=0
rdev=00:00
This is what the program looks like:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/fcntl.h>
#include <sys/personality.h>
int main()
{
/* touch temp file */
system("rm -f /tmp/pers32_check");
system("touch /tmp/pers32_check");
/* setup filtering rule */
system("/sbin/auditctl -D");
system("/sbin/auditctl -a entry,always -S open -F pers=0x08");
/* execute open syscall */
personality(0x08);
open("/tmp/pers32_check", O_RDONLY);
printf("Personality: %ld\n", personality(0xffffffff));
return 0;
}
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
2:34 p.m.
New subject: syscall filtering on personality
On Tuesday 08 March 2005 15:18, Debora Velarde wrote:
So it looks like, if you add a syscall by name to auditctl, it always
adds
only the rule for the 64bit syscall number.
Actually, this should be the syscall number that auditctl was compiled with.
Should auditctl add both?
I don't think so. How does it know what personalities you want to watch?
Or should auditctl use the pers flag to figure out which syscall
number to
add?
How about we make pers take a list? This could be implemented one of 2 ways.
auditctl can generate a rule for each personality. Or with some changes in
the kernel, we can make personality act more like a bit mask so that we don't
have to load as many rules in the kernel.
Userspace can generate a mask or separate rules. Any preferences?
-Steve
3:13 p.m.
New subject: syscall filtering on personality
Before we decide to use the pers flag for this, I want to understand
personality more.
I added an additional
printf("Personality: %ld\n", personality(0xffffffff));
statement in the test case before you make the call
personality(0x08);
Before you explicitly set personality to 8 in the test, personality is
always=0 whether you compile the test in 64bit or 32bit mode.
Is that the expected behavior? Can you not tell from personality if
something was compiled in 32bit vs 64bit mode?
-debbie
Steve Grubb
<sgrubb(a)redhat.co
m> To
Sent by: Linux Audit Discussion
linux-audit-bounc <linux-audit(a)redhat.com>
es(a)redhat.com cc
Subject
03/08/2005 02:34 Re: syscall filtering on
PM personality
Please respond to
Linux Audit
Discussion
On Tuesday 08 March 2005 15:18, Debora Velarde wrote:
So it looks like, if you add a syscall by name to auditctl, it always
adds
only the rule for the 64bit syscall number.
Actually, this should be the syscall number that auditctl was compiled
with.
Should auditctl add both?
I don't think so. How does it know what personalities you want to watch?
Or should auditctl use the pers flag to figure out which syscall
number
to
add?
How about we make pers take a list? This could be implemented one of 2
ways.
auditctl can generate a rule for each personality. Or with some changes in
the kernel, we can make personality act more like a bit mask so that we
don't
have to load as many rules in the kernel.
Userspace can generate a mask or separate rules. Any preferences?
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
7424
days inactive
7430
days old
linux-audit@lists.linux-audit.osci.io
4 comments
2 participants
participants (2)
-
Debora Velarde -
Steve Grubb