Linux-audit Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Kangkook Jee <aixer77@gmail.com>
To: linux-audit@redhat.com
Subject: Re: Early processes (daemons) do not report audit events
Date: Thu, 10 Sep 2015 16:53:57 -0400	[thread overview]
Message-ID: <087AE25B-79B6-4E7A-BE4B-901BE95FB81B@gmail.com> (raw)
In-Reply-To: <1E6087D5-E362-4795-BD8D-1374831498E4@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2268 bytes --]

Hi all,

I debugged a bit further to identify distributions that are affected by the issue.
I repeated the same experiment with sshd from 3 more distributions.

CentOS Linux release 7.1.1503 (64-bit, 3.10.0-229.el7.x86_64): Problem NOT reproduced
CentOS release 6.6 (64-bit, 2.6.32-504.el6.x86_64): Problem NOT reproduced
Ubuntu 12.04.5 LTS (64-bit, 3.13.0-32-generic): Problem reproduced

After all, Ubuntu family are affected by the issue and I could confirm that results are inconsistent 
across two different distribution families. 

If you can let us know how can we workaround the issue, it will be a great help.

Regards, Kangkook


> On Sep 9, 2015, at 11:50 PM, Kangkook Jee <aixer77@gmail.com> wrote:
> 
> Dear all,
> 
> We are developing custom user space audit agent to gather system wide system
> call trace. While experimenting with various programs, we found out that
> processes (daemons) that started early (along with the system bootstrapping) do
> not report any audit events at all. These processes typically fall into PID
> range of less than 2000. Here’s how I reproduced the symptom with sshd daemon.
> 
> 1. Reboot the system
> 
> 2. Add and enable audit events
>    # /sbin/auditctl -a exit,always -F arch=b64 -S clone -S close -S creat -S dup
>           -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat 
>           -S unlink -S unlinkat -S vfork -S 288 -S accept -S bind -S connect 
>           -S listen -S socket -S socketpair
>    # /sbin/auditctl -e1 -b 102400
> 
> 3. Connect to the system via ssh
>     Audit messages generated only from child processes and none are seen from
>     the original daemon.
> 
> 4. Restart sshd 
>     # restart ssh
> 
> 5. Connect again to the system via ssh
>    Now, we see audit messages from both parent and child processes.
> 
> I did the experiment from Ubuntu 14.04.2 LTS distribution (64-bit, kernel
> version 3.13.0-58-generic).
> 
> I first wonder whether this is intended behavior of audit framework or
> not. If it is intended, I also want to know how can we configure auditd
> differently to capture system calls from all processes. 
> 
> Thanks a lot for your help in advance!
> 
> Regards, Kangkook
> 


[-- Attachment #1.2: Type: text/html, Size: 4184 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2015-09-10 20:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-10  3:50 Early processes (daemons) do not report audit events Kangkook Jee
2015-09-10 20:53 ` Kangkook Jee [this message]
2015-09-11  9:50   ` Richard Guy Briggs
2015-09-11 11:03     ` Kangkook Jee
2015-09-11 11:45     ` Kangkook Jee
2015-09-11 16:24       ` Richard Guy Briggs
2015-09-11 20:17         ` Kangkook Jee
2015-09-13 15:58           ` Richard Guy Briggs
2015-09-16 13:08             ` Kangkook Jee

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=087AE25B-79B6-4E7A-BE4B-901BE95FB81B@gmail.com \
    --to=aixer77@gmail.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