Dear Richard,

Thanks a lot for your reply. Please refer to my inlined replies. 

Btw, we can stably re-produce the issue with most of Ubuntu distribution
families. I think we can ship you a VM image (via Amazon S3 or something) so as
to save your time debugging it.

Thanks a lot for your help again!

Regards, Kangkook

On Sep 11, 2015, at 5:50 AM, Richard Guy Briggs <rgb@redhat.com> wrote:

On 15/09/10, Kangkook Jee wrote:
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

For each of these examples, what is the value of the kernel command line
"audit=<value>" if it is even present?  It is possible that the CentOS
examples include "audit=1" while Ubuntu omits the line.  "cat
/proc/cmdline" should tell you the answer.


For all testcases, I used the same auditctl options to set up rules and I didn’t set any audit=<value> entries.
And options as same as I presented from the previous email. 

  # /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

And I personally don’t think audit=<value> would become an issue here, since
audit framework began to capture events from sshd daemon as soon as we restarted
it without making any changes. sshd was running with the same uid (or auid) and
the same permissions. 

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

I would be curious what your results are with a recent Debian and with a
recent Fedora.


I will redo the same experiment with those distribution and let you know how it goes. 


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



--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit


- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545