syscall filtering on personality

[Debora Velarde]

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 at 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 at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20050308/7265b61e/attachment.htm>