audit more syscalls during boot before auditd starts?

audit more syscalls during boot before auditd starts?

[Giang Nguyen]

Hi,
I am running Ubuntu 12.04 with audit 1.7.18. I notice that if I
specify the kernel boot parameter audit=1 (according to auditd(8)),
then the kernel audits some syscalls to /var/log/syslog before auditd
starts.
However, I am seeing only syscall=1 (write()). I assume there are more
syscalls like fork/clone() and execve() that are not being audited.
Can I make the kernel -- via boot/runtime configuration, not
recompilation -- audit more syscalls before auditd starts?
I googled but did not find the answer or even this exact question.

Jul 19 20:57:53 host kernel: [    0.000000] Command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-23-generic ... audit=1
Jul 19 20:57:53 host kernel: [    0.000000] Kernel command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-23-generic ... audit=1
Jul 19 20:57:53 host kernel: [    0.000000] audit: enabled (after
initialization)
Jul 19 20:57:53 host kernel: [    0.701807] audit: initializing
netlink socket (enabled)
Jul 19 20:57:53 host kernel: [    0.701813] type=2000
audit(1342731461.540:1): initialized
Jul 19 20:57:53 host kernel: [   10.112334] type=1400
audit(1342745872.190:2): apparmor="STATUS" operation="profile_load"
name="/sbin/dhclient" pid=393 comm="apparmor_parser"
Jul 19 20:57:53 host kernel: [   10.112341] type=1400
audit(1342745872.190:3): apparmor="STATUS" operation="profile_replace"
name="/sbin/dhclient" pid=550 comm="apparmor_parser"
Jul 19 20:57:53 host kernel: [   10.112345] type=1300
audit(1342745872.190:2): arch=c000003e syscall=1 success=yes
exit=70195 ... exe="/sbin/apparmor_parser" key=(null)
Jul 19 20:57:53 host kernel: [   10.112353] type=1300
audit(1342745872.190:3): arch=c000003e syscall=1 success=yes
exit=70195 ... exe="/sbin/apparmor_parser" key=(null)
...
...
Jul 19 20:58:16 host auditd[1217]: Init complete, auditd 1.7.18
listening for events (startup state enable)
Jul 19 20:58:16 host kernel: [   34.614216] auditd (1217):
/proc/1217/oom_adj is deprecated, please use /proc/1217/oom_score_adj
instead.

Thanks.

Re: audit more syscalls during boot before auditd starts?

[Steve Grubb]

On Friday, July 20, 2012 10:07:33 AM Giang Nguyen wrote:
> Hi,
> I am running Ubuntu 12.04 with audit 1.7.18. I notice that if I
> specify the kernel boot parameter audit=1 (according to auditd(8)),
> then the kernel audits some syscalls to /var/log/syslog before auditd
> starts.

This is not really "normal". There are MAC systems that can cause certain 
events to be audited and perhaps that is what you are seeing. Maybe apparmor 
is triggering the audit events?

There are certain events that are audited during boot and they are hardwired 
so that no rules are needed. These events are audited to prove that certain 
assumptions about the system policy are true, like MAC policy loading or 
changes to its configuration.

But the audit rules that are normally used are discretionary. They need to be 
loaded before a user has access to a system. Just so long as they get loaded 
before a user logs in is all that matters. System security events are usually 
queued in memory and the audit system drains the queue as soon as it starts. 
But the security posture of the system does not mean that rules have to be 
loaded extremely early in the boot process.

That said, there have been attempts to reconstruct the boot using the audit 
system. I think bootchart.org used it and maybe the readahead bootloader. They 
were programs that I think were in the initramfs and loaded hardcoded rules 
into the kernel. But the problem was that they sort of interfere with the 
audit daemon. Their goals are mutually exclusive to security concerns. 
Performance analysis and security don't work together.

But even if you successfully load rules early...you need a daemon to collect 
the results before the internal kernel buffer overflows and forever lose the 
events. So, this means getting the audit daemon running earlier and its main 
requirement is the MAC policy already be loaded and the disk system mounted 
(perhaps networking running if you use remote logging).

Hope this helps...

-Steve


> However, I am seeing only syscall=1 (write()). I assume there are more
> syscalls like fork/clone() and execve() that are not being audited.
> Can I make the kernel -- via boot/runtime configuration, not
> recompilation -- audit more syscalls before auditd starts?
> I googled but did not find the answer or even this exact question.
> 
> Jul 19 20:57:53 host kernel: [    0.000000] Command line:
> BOOT_IMAGE=/boot/vmlinuz-3.2.0-23-generic ... audit=1
> Jul 19 20:57:53 host kernel: [    0.000000] Kernel command line:
> BOOT_IMAGE=/boot/vmlinuz-3.2.0-23-generic ... audit=1
> Jul 19 20:57:53 host kernel: [    0.000000] audit: enabled (after
> initialization)
> Jul 19 20:57:53 host kernel: [    0.701807] audit: initializing
> netlink socket (enabled)
> Jul 19 20:57:53 host kernel: [    0.701813] type=2000
> audit(1342731461.540:1): initialized
> Jul 19 20:57:53 host kernel: [   10.112334] type=1400
> audit(1342745872.190:2): apparmor="STATUS" operation="profile_load"
> name="/sbin/dhclient" pid=393 comm="apparmor_parser"
> Jul 19 20:57:53 host kernel: [   10.112341] type=1400
> audit(1342745872.190:3): apparmor="STATUS" operation="profile_replace"
> name="/sbin/dhclient" pid=550 comm="apparmor_parser"
> Jul 19 20:57:53 host kernel: [   10.112345] type=1300
> audit(1342745872.190:2): arch=c000003e syscall=1 success=yes
> exit=70195 ... exe="/sbin/apparmor_parser" key=(null)
> Jul 19 20:57:53 host kernel: [   10.112353] type=1300
> audit(1342745872.190:3): arch=c000003e syscall=1 success=yes
> exit=70195 ... exe="/sbin/apparmor_parser" key=(null)
> ...
> ...
> Jul 19 20:58:16 host auditd[1217]: Init complete, auditd 1.7.18
> listening for events (startup state enable)
> Jul 19 20:58:16 host kernel: [   34.614216] auditd (1217):
> /proc/1217/oom_adj is deprecated, please use /proc/1217/oom_score_adj
> instead.
> 
> Thanks.
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: audit more syscalls during boot before auditd starts?

[Giang Nguyen]

> But even if you successfully load rules early...you need a daemon to collect
> the results before the internal kernel buffer overflows and forever lose the
> events. So, this means getting the audit daemon running earlier and its main
> requirement is the MAC policy already be loaded and the disk system mounted
> (perhaps networking running if you use remote logging).

Thanks, Steve.