Re: Early processes (daemons) do not report audit events

[Richard Guy Briggs <rgb@redhat.com>]

On 15/09/11, Kangkook Jee wrote:
> From the previous reply, I think I misunderstood your question regarding kernel command line. 
> Here’s "cat /proc/cmdline” results for distributions that I’ve experimented. 
> 
> Ubuntu 14.04 (64-bit): 
>     BOOT_IMAGE=/boot/vmlinuz-3.13.0-58-generic root=UUID=7505f862-ce46-49e5-9d1c-e4e307844889 ro text quiet splash vt.handoff=7
> 
> Ubuntu 12.04 (64-bit): 
>     BOOT_IMAGE=/boot/vmlinuz-3.13.0-32-generic root=UUID=5be789be-9b0c-463e-bd18-42bfa79fb24c ro quiet splash
> 
> CentOS 7 (64-bit): 
>     BOOT_IMAGE=/vmlinuz-3.10.0-229.el7.x86_64 root=/dev/mapper/centos-root ro rd.lvm.lv=centos/root rd.lvm.lv=centos/swap crashkernel=auto rhgb quiet LANG=en_US.UTF-8
> 
> CentOS 6 (64-bit): 
>     ro root=UUID=a7d44560-adcc-4000-9584-8b9fcf2afd74 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=129M@0M  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
> 
> I don’t see any audit=<value> entries from all examples above. 

Yes, this is what I was seeking from you.  And you are correct, none of
them have audit=1 as I was hoping from at least CentOS.  There is a
chance that the CentOS kernel was compiled with audit=1 hardcoded, but I
think that is a pretty small chance...

I'll have to look at this closer...  But any Debian and Fedora data
points that you can provide would certainly be useful.

> /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.
> > 
> >> 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.
> > 
> >> 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 <mailto:Linux-audit@redhat.com>
> >> https://www.redhat.com/mailman/listinfo/linux-audit <https://www.redhat.com/mailman/listinfo/linux-audit>
> > 
> > 
> > - RGB
> > 
> > --
> > Richard Guy Briggs <rbriggs@redhat.com <mailto: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
> 

- 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

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