From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: audit more syscalls during boot before auditd starts?
Date: Fri, 20 Jul 2012 10:56:26 -0400 [thread overview]
Message-ID: <1790072.tx1ZMPhs0h@x2> (raw)
In-Reply-To: <CAEryOqWoKnM8rFTNP0y_Dv0XT6gTD3Wt7HhvJp4LWhObsmhbqw@mail.gmail.com>
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
next prev parent reply other threads:[~2012-07-20 14:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-20 14:07 audit more syscalls during boot before auditd starts? Giang Nguyen
2012-07-20 14:56 ` Steve Grubb [this message]
2012-07-23 14:42 ` Giang Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1790072.tx1ZMPhs0h@x2 \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox