AUDIT SYSCALL kernel configuration option on ARM ?

[Laszlo Papp]

On Fri, Jan 28, 2011 at 3:25 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> On Friday, January 28, 2011 07:46:13 am Laszlo Papp wrote:
>> On Thu, Jan 27, 2011 at 3:53 PM, Steve Grubb <sgrubb at redhat.com> wrote:
>> > If no one wants to help, then I have to wait until someone finally
>> > decides to fix it.
>>
>> I see, Steve. Unfortunately I cannot help because I do not have too
>> much kernel programming experience. The real problem why I wanted to
>> give a glimpse for AUDIT because upstart cannot print out the process
>> ID information about the commands that were run from the
>> pre/post-start/stop section of the /etc/init/*.conf upstart config/job
>> files.
>
> I suspect you could patch upstart to record this information. Where to put it is the
> main question since the only thing that might be accesible is /.

What is wrong about '/' then ?

>> I has been told so that audit could be used in this special case for
>> my purpose. The first question is that whether or not kernel's
>> audit-properties can be used without the SYSCALL configuration option
>> - so basically just with the "default one" -  to get more accurate
>> information about the processes upstart launches during the boot-up.
>
> Not really. You would have to patch upstart to send audit events. But assuming you had
> support for this on ARM processors, the audit system has a start priority of 11 using
> the old SysVinit style of startup. If you use LSB style startups, then you will find
> more disappointing news because my calls for an audit facility have also went
> unanswered. They have a syslog facility, but no one seems to care about audit. So,
> whenever the audit system finally starts up, you could use a rule like this:
>
> -a always,exit -S execve -F ppid=1 -k init
>
> and you can use the key, init, for searching
>
> ausearch --start today -k init
>
> There is a readahead collector that could probably be hacked to record process
> information rather than file loading information. The following location has some info
> and links on profiling startup:
>
> http://fedoraproject.org/wiki/Features/30SecondStartup/ReadAheadReloaded

Let me summarize how I realized this post of yours and do not hesitate
to slap me if I am mistaken :) :
There is no current support for ARM processor and LSB style
initscripts and the prospect is rather poor due to your past
experience. (about asking help)
On the top of the previous problematic statement, situation I should
write an upstart patch to support audit, anyway. It does not sound too
perspective :/.

Do you think that I can avoid the audit usage and patch upstart with a
sysvinit-like bootlogd functionaility ?
(http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/bootlogd.c?root=sysvinit&view=markup).
After this discussion the upstart extension seems the most reasonable
way to do it (the only viable though).

Thank you in advance!

Best Regards,
Laszlo Papp