From: Kangkook Jee <aixer77@gmail.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: Early processes (daemons) do not report audit events
Date: Fri, 11 Sep 2015 16:17:56 -0400 [thread overview]
Message-ID: <43B84A86-63BA-4573-9F12-5510E5E404DD@gmail.com> (raw)
In-Reply-To: <20150911162438.GQ8140@madcap2.tricolour.ca>
[-- Attachment #1.1: Type: text/plain, Size: 6011 bytes --]
Hi Richard,
I also did the same experiment for the latest distributions of Fedora core and Debian and here’s the results.
Fedora-22 (64-bit, 4.0.4-301.fc22.x86_64): Problem reproduced.
Debian-8 (64-bit, 3.16.0-4-amd64): Problem reproduced
Btw, Burn Alting (burn@swtf.dyndns.org) suggested me to append audit=1 to kernel flag. I added the option to boot-loader (grub) and problem went away.
Regards, Kangkook
> On Sep 11, 2015, at 12:24 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
>
> 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> <mailto: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> <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> <mailto: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 <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
[-- Attachment #1.2: Type: text/html, Size: 20857 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2015-09-11 20:17 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
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 [this message]
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=43B84A86-63BA-4573-9F12-5510E5E404DD@gmail.com \
--to=aixer77@gmail.com \
--cc=linux-audit@redhat.com \
--cc=rgb@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