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=3D<value>" if it is even present? = It is possible that the CentOS
examples include "audit=3D1" 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=E2=80=99t set any audit=3D<value> entries.

And = options as same as I presented from the previous = email.

# /sbin/auditctl -a exit,always -F arch=3Db64 -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=E2=80=99t think = audit=3D<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=E2=80=99s 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=3Db64 -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