AUDIT SYSCALL kernel configuration option on ARM ?

AUDIT SYSCALL kernel configuration option on ARM ?

[Laszlo Papp]

Hi,

I have just faced into this issue weeks ago.
This is the related thread:
http://www.linuxquestions.org/questions/showthread.php?p=4231159#post4231159

Any 2 cents on the matter or plan, schedule when to fix it ?

Best Regards,
Laszlo Papp

Re: AUDIT SYSCALL kernel configuration option on ARM ?

[Steve Grubb]

On Thursday, January 27, 2011 07:19:16 am Laszlo Papp wrote:
> I have just faced into this issue weeks ago.
> This is the related thread:
> http://www.linuxquestions.org/questions/showthread.php?p=4231159#post423115
> 9
> 
> Any 2 cents on the matter or plan, schedule when to fix it ?

I added user space support quite a while back and asked for kernel help. No one 
answered:

http://lists.fedoraproject.org/pipermail/arm/2009-October/000382.html

If no one wants to help, then I have to wait until someone finally decides to fix it.

-Steve

Re: AUDIT SYSCALL kernel configuration option on ARM ?

[Laszlo Papp]

On Thu, Jan 27, 2011 at 3:53 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Thursday, January 27, 2011 07:19:16 am Laszlo Papp wrote:
>> I have just faced into this issue weeks ago.
>> This is the related thread:
>> http://www.linuxquestions.org/questions/showthread.php?p=4231159#post423115
>> 9
>>
>> Any 2 cents on the matter or plan, schedule when to fix it ?
>
> I added user space support quite a while back and asked for kernel help. No one
> answered:
>
> http://lists.fedoraproject.org/pipermail/arm/2009-October/000382.html
>
> If no one wants to help, then I have to wait until someone finally decides to fix it.
>
> -Steve

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 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.

Thank you in advance!

Best Regards,
Laszlo Papp

Re: AUDIT SYSCALL kernel configuration option on ARM ?

[Steve Grubb]

On Friday, January 28, 2011 07:46:13 am Laszlo Papp wrote:
> On Thu, Jan 27, 2011 at 3:53 PM, Steve Grubb <sgrubb@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 /.

> 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

-Steve

Re: AUDIT SYSCALL kernel configuration option on ARM ?

[Laszlo Papp]

On Fri, Jan 28, 2011 at 3:25 PM, Steve Grubb <sgrubb@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@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