* Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd
From: Paul Moore @ 2015-09-11 18:56 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: Paul Moore, v.rathor, linux-kernel, linux-audit
In-Reply-To: <20150911102114.GP8140@madcap2.tricolour.ca>
On Fri, Sep 11, 2015 at 6:21 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 15/09/09, Paul Moore wrote:
>> On Monday, September 07, 2015 12:58:18 PM Richard Guy Briggs wrote:
>> > On 15/09/07, Richard Guy Briggs wrote:
>> > > Nothing prevents a new auditd starting up and replacing a valid
>> > > audit_pid when an old auditd is still running, effectively starving out
>> > > the old auditd since audit_pid no longer points to the old valid auditd.
>> > >
>> > > There isn't an easy way to detect if an old auditd is still running on
>> > > the existing audit_pid other than attempting to send a message to see if
>> > > it fails. If no message to auditd has been attempted since auditd died
>> > > unnaturally or got killed, audit_pid will still indicate it is alive.
>> > >
>> > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
>> >
>> > Ok, self-nack on this one for a couple of problems...
>> > netlink_getsockbyportid() is static to af_netlink.c and "pid" should be
>> > task_tgid_vnr(current). Otherwise, any opinions on this approach?
>> >
>> > > ---
>> > > Note: Would it be too bold to actually block the registration of a new
>> > > auditd if the netlink_getsockbyportid() call succeeded? Would other
>> > > checks be appropriate?
>>
>> Hmm. It seems like we should prevent the registration of a new auditd if we
>> already have an auditd instance connected, although as you say, that isn't the
>> easiest thing to do.
>
> I wanted to do that, but I feared it would carry some risk that an
> intentional act would be blocked. In that case, an intentional act
> could include explicitly killing the old auditd (or process registered
> as such).
Well, if you are running another instance of auditd you should have
the right level of access to kill an older, existing auditd instance
so I'm not too worried about preventing an intentional act. Also, if
we check an existing connection with some sort of heartbeat/ping
message we wouldn't be preventing it for more than a few times I
believe.
>> How painful would it be to return -EAGAIN to the new auditd while sending some
>> sort of keep-alive/ping/etc. message to the old daemon to check its status?
>
> Well, if it turns out that the only reason it ever fails is
> -ECONNREFUSED, then we just need to check with netlink_getsockbyportid()
> to see if it fails before accepting the new auditd.
I'm not sure if the netdev crowd would be interested in exporting
_getsockbyportid(); for the sake of discussion let's assume no changes
to the netlink layer, if we get stuck we can revisit this idea.
> If it is one of the others, can we put the new auditd task on a wait
> queue until we hear back one way or the other or just timeout on
> contacting the old auditd?
Well, what if we don't have anything queued for the old auditd?
Although I suppose if nothing else we could send a record indicating
that another auditd attempted to replace it ... if we can send it
great, drop the new request and be glad we audited it, if we can't
send it, reset the auditd tracking.
> I'll let Steve speak to dealing with -EAGAIN. auditlib already deals
> with -EAGAIN and -EINTR for some cases. I have a patch that added
> -ENOBUFS to those cases since I had seen some reports that -ENOBUFS had
> been returned in some cases (don't remember the circumstances).
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: Early processes (daemons) do not report audit events
From: Richard Guy Briggs @ 2015-09-11 16:24 UTC (permalink / raw)
To: Kangkook Jee; +Cc: linux-audit
In-Reply-To: <8C676625-C8EF-4BDD-B5AA-4C2CC50B2BB0@gmail.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
^ permalink raw reply
* Re: Early processes (daemons) do not report audit events
From: Kangkook Jee @ 2015-09-11 11:45 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20150911095027.GO8140@madcap2.tricolour.ca>
[-- Attachment #1.1: Type: text/plain, Size: 4339 bytes --]
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.
/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
[-- Attachment #1.2: Type: text/html, Size: 19940 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Early processes (daemons) do not report audit events
From: Kangkook Jee @ 2015-09-11 11:03 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20150911095027.GO8140@madcap2.tricolour.ca>
[-- Attachment #1.1: Type: text/plain, Size: 4553 bytes --]
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 <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
[-- Attachment #1.2: Type: text/html, Size: 20605 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd
From: Richard Guy Briggs @ 2015-09-11 10:21 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, linux-kernel, sgrubb, eparis, v.rathor, ctcard
In-Reply-To: <4246819.OGLW0CmS4i@sifl>
On 15/09/09, Paul Moore wrote:
> On Monday, September 07, 2015 12:58:18 PM Richard Guy Briggs wrote:
> > On 15/09/07, Richard Guy Briggs wrote:
> > > Nothing prevents a new auditd starting up and replacing a valid
> > > audit_pid when an old auditd is still running, effectively starving out
> > > the old auditd since audit_pid no longer points to the old valid auditd.
> > >
> > > There isn't an easy way to detect if an old auditd is still running on
> > > the existing audit_pid other than attempting to send a message to see if
> > > it fails. If no message to auditd has been attempted since auditd died
> > > unnaturally or got killed, audit_pid will still indicate it is alive.
> > >
> > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> >
> > Ok, self-nack on this one for a couple of problems...
> > netlink_getsockbyportid() is static to af_netlink.c and "pid" should be
> > task_tgid_vnr(current). Otherwise, any opinions on this approach?
> >
> > > ---
> > > Note: Would it be too bold to actually block the registration of a new
> > > auditd if the netlink_getsockbyportid() call succeeded? Would other
> > > checks be appropriate?
>
> Hmm. It seems like we should prevent the registration of a new auditd if we
> already have an auditd instance connected, although as you say, that isn't the
> easiest thing to do.
I wanted to do that, but I feared it would carry some risk that an
intentional act would be blocked. In that case, an intentional act
could include explicitly killing the old auditd (or process registered
as such).
> How painful would it be to return -EAGAIN to the new auditd while sending some
> sort of keep-alive/ping/etc. message to the old daemon to check its status?
Well, if it turns out that the only reason it ever fails is
-ECONNREFUSED, then we just need to check with netlink_getsockbyportid()
to see if it fails before accepting the new auditd.
If it is one of the others, can we put the new auditd task on a wait
queue until we hear back one way or the other or just timeout on
contacting the old auditd?
I'll let Steve speak to dealing with -EAGAIN. auditlib already deals
with -EAGAIN and -EINTR for some cases. I have a patch that added
-ENOBUFS to those cases since I had seen some reports that -ENOBUFS had
been returned in some cases (don't remember the circumstances).
> paul moore
- 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
^ permalink raw reply
* Re: Early processes (daemons) do not report audit events
From: Richard Guy Briggs @ 2015-09-11 9:50 UTC (permalink / raw)
To: Kangkook Jee; +Cc: linux-audit
In-Reply-To: <087AE25B-79B6-4E7A-BE4B-901BE95FB81B@gmail.com>
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
> 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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Early processes (daemons) do not report audit events
From: Kangkook Jee @ 2015-09-10 20:53 UTC (permalink / raw)
To: linux-audit
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 --]
^ permalink raw reply
* Early processes (daemons) do not report audit events
From: Kangkook Jee @ 2015-09-10 3:50 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 1457 bytes --]
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: 2650 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd
From: Paul Moore @ 2015-09-09 20:50 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: linux-audit, linux-kernel, sgrubb, eparis, v.rathor, ctcard
In-Reply-To: <20150907165818.GH8140@madcap2.tricolour.ca>
On Monday, September 07, 2015 12:58:18 PM Richard Guy Briggs wrote:
> On 15/09/07, Richard Guy Briggs wrote:
> > Nothing prevents a new auditd starting up and replacing a valid
> > audit_pid when an old auditd is still running, effectively starving out
> > the old auditd since audit_pid no longer points to the old valid auditd.
> >
> > There isn't an easy way to detect if an old auditd is still running on
> > the existing audit_pid other than attempting to send a message to see if
> > it fails. If no message to auditd has been attempted since auditd died
> > unnaturally or got killed, audit_pid will still indicate it is alive.
> >
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
>
> Ok, self-nack on this one for a couple of problems...
> netlink_getsockbyportid() is static to af_netlink.c and "pid" should be
> task_tgid_vnr(current). Otherwise, any opinions on this approach?
>
> > ---
> > Note: Would it be too bold to actually block the registration of a new
> > auditd if the netlink_getsockbyportid() call succeeded? Would other
> > checks be appropriate?
Hmm. It seems like we should prevent the registration of a new auditd if we
already have an auditd instance connected, although as you say, that isn't the
easiest thing to do.
How painful would it be to return -EAGAIN to the new auditd while sending some
sort of keep-alive/ping/etc. message to the old daemon to check its status?
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCH V2] audit: try harder to send to auditd upon netlink failure
From: Paul Moore @ 2015-09-09 20:41 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: linux-audit, linux-kernel, sgrubb, eparis, v.rathor, ctcard
In-Reply-To: <8a3693df3e804bffdd0bf148fb1793d684bf9bbf.1441614933.git.rgb@redhat.com>
On Monday, September 07, 2015 05:10:13 AM Richard Guy Briggs wrote:
> There are several reports of the kernel losing contact with auditd when
> it is, in fact, still running. When this happens, kernel syslogs show:
> "audit: *NO* daemon at audit_pid=<pid>"
> although auditd is still running, and is apparently happy, listening on
> the netlink socket. The pid in the "*NO* daemon" message matches the pid
> of the running auditd process. Restarting auditd solves this.
>
> The problem appears to happen randomly, and doesn't seem to be strongly
> correlated to the rate of audit events being logged. The problem
> happens fairly regularly (every few days), but not yet reproduced to
> order.
>
> On production kernels, BUG_ON() is a no-op, so any error will trigger
> this.
>
> Commit 34eab0a7cd45 ("audit: prevent an older auditd shutdown from
> orphaning a newer auditd startup") eliminates one possible cause. This
> isn't the case here, since the PID in the error message and the PID of
> the running auditd match.
>
> The primary expected cause of error here is -ECONNREFUSED when the audit
> daemon goes away, when netlink_getsockbyportid() can't find the auditd
> portid entry in the netlink audit table (or there is no receive
> function). If -EPERM is returned, that situation isn't likely to be
> resolved in a timely fashion without administrator intervention. In
> both cases, reset the audit_pid. This does not rule out a race
> condition. SELinux is expected to return zero since this isn't an INET
> or INET6 socket. Other LSMs may have other return codes. Log the error
> code for better diagnosis in the future.
>
> In the case of -ENOMEM, the situation could be temporary, based on local
> or general availability of buffers. -EAGAIN should never happen since
> the netlink audit (kernel) socket is set to MAX_SCHEDULE_TIMEOUT.
> -ERESTARTSYS and -EINTR are not expected since this kernel thread is not
> expected to receive signals. In these cases (or any other unexpected
> ones for now), report the error and re-schedule the thread, retrying up
> to 5 times.
>
> v2:
> Removed BUG_ON().
> Moved comma in pr_*() statements.
> Removed audit_strerror() text.
>
> Reported-by: Vipin Rathor <v.rathor@gmail.com>
> Reported-by: <ctcard@hotmail.com>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/audit.c | 24 +++++++++++++++++++-----
> 1 files changed, 19 insertions(+), 5 deletions(-)
Queued up for linux-audit#next as soon as 4.3-rc1 is released.
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 1c13e42..18cdfe2 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -407,16 +407,30 @@ static void audit_printk_skb(struct sk_buff *skb)
> static void kauditd_send_skb(struct sk_buff *skb)
> {
> int err;
> + int attempts = 0;
> +#define AUDITD_RETRIES 5
> +
> +restart:
> /* take a reference in case we can't send it and we want to hold it */
> skb_get(skb);
> err = netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
> if (err < 0) {
> - BUG_ON(err != -ECONNREFUSED); /* Shouldn't happen */
> + pr_err("netlink_unicast sending to audit_pid=%d returned error: %d\n",
> + audit_pid, err);
> if (audit_pid) {
> - pr_err("*NO* daemon at audit_pid=%d\n", audit_pid);
> - audit_log_lost("auditd disappeared");
> - audit_pid = 0;
> - audit_sock = NULL;
> + if (err == -ECONNREFUSED || err == -EPERM
> + || ++attempts >= AUDITD_RETRIES) {
> + audit_log_lost("audit_pid=%d reset");
> + audit_pid = 0;
> + audit_sock = NULL;
> + } else {
> + pr_warn("re-scheduling(#%d) write to audit_pid=%d\n",
> + attempts, audit_pid);
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule();
> + __set_current_state(TASK_RUNNING);
> + goto restart;
> + }
> }
> /* we might get lucky and get this in the next auditd */
> audit_hold_skb(skb);
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd
From: Richard Guy Briggs @ 2015-09-09 6:31 UTC (permalink / raw)
To: Eric Paris; +Cc: linux-audit, linux-kernel, sgrubb, pmoore, v.rathor, ctcard
In-Reply-To: <1441724246.27892.89.camel@redhat.com>
On 15/09/08, Eric Paris wrote:
> This is already going to be in the audit log, right? We're going to
> send a CONFIG_CHANGE record with old_pid == the existing auditd. I bet
> it gets delivered to the old auditd.
Actually, delivered by the new auditd is what I'm seeing... (Tested by
running "auditd -f" to have it show up in the debug output and not in
the log file.) I did see it once as two seperate messages, one setting
to zero and the next to the new PID, but that may have been a testing
procedure error...
(Note: Why does auditd run in a terminal with -n or -f not respond to ^C?)
> But why is this a printk(KERN_WARN) ?
Because we're still trying to figure out what is going on... But point
taken, we already should have that information. If it is listed as a
warning it has a better chance of getting reported. What do you suggest
instead?
Eric, thanks for taking the time to review this...
> On Mon, 2015-09-07 at 12:48 -0400, Richard Guy Briggs wrote:
> > Nothing prevents a new auditd starting up and replacing a valid
> > audit_pid when an old auditd is still running, effectively starving out
> > the old auditd since audit_pid no longer points to the old valid auditd.
> >
> > There isn't an easy way to detect if an old auditd is still running on
> > the existing audit_pid other than attempting to send a message to see if
> > it fails. If no message to auditd has been attempted since auditd died
> > unnaturally or got killed, audit_pid will still indicate it is alive.
> >
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > Note: Would it be too bold to actually block the registration of a new
> > auditd if the netlink_getsockbyportid() call succeeded? Would other
> > checks be appropriate?
> >
> > kernel/audit.c | 5 +++++
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 18cdfe2..1fa1e0d 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -872,6 +872,11 @@ static int audit_receive_msg(struct sk_buff
> > *skb, struct nlmsghdr *nlh)
> > if (s.mask & AUDIT_STATUS_PID) {
> > int new_pid = s.pid;
> >
> > + if (audit_pid && new_pid &&
> > + !IS_ERR(netlink_getsockbyportid(audit_sock, audit_nlk_portid)))
> > + pr_warn("auditd replaced by new auditd before normal shutdown: "
> > + "(old)audit_pid=%d (by)pid=%d new_pid=%d",
> > + audit_pid, pid, new_pid);
> > if ((!new_pid) && (task_tgid_vnr(current) != audit_pid))
> > return -EACCES;
> > if (audit_enabled != AUDIT_OFF)
- 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
^ permalink raw reply
* Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd
From: Eric Paris @ 2015-09-08 14:57 UTC (permalink / raw)
To: Richard Guy Briggs, linux-audit, linux-kernel
Cc: sgrubb, pmoore, v.rathor, ctcard
In-Reply-To: <5e786f07b6d8a19927c70345c14bd1a452164d38.1441644314.git.rgb@redhat.com>
This is already going to be in the audit log, right? We're going to
send a CONFIG_CHANGE record with old_pid == the existing auditd. I bet
it gets delivered to the old auditd.
But why is this a printk(KERN_WARN) ?
On Mon, 2015-09-07 at 12:48 -0400, Richard Guy Briggs wrote:
> Nothing prevents a new auditd starting up and replacing a valid
> audit_pid when an old auditd is still running, effectively starving
> out
> the old auditd since audit_pid no longer points to the old valid
> auditd.
>
> There isn't an easy way to detect if an old auditd is still running
> on
> the existing audit_pid other than attempting to send a message to see
> if
> it fails. If no message to auditd has been attempted since auditd
> died
> unnaturally or got killed, audit_pid will still indicate it is alive.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> Note: Would it be too bold to actually block the registration of a
> new
> auditd if the netlink_getsockbyportid() call succeeded? Would other
> checks be appropriate?
>
> kernel/audit.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 18cdfe2..1fa1e0d 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -872,6 +872,11 @@ static int audit_receive_msg(struct sk_buff
> *skb, struct nlmsghdr *nlh)
> if (s.mask & AUDIT_STATUS_PID) {
> int new_pid = s.pid;
>
> + if (audit_pid && new_pid &&
> +
> !IS_ERR(netlink_getsockbyportid(audit_sock, audit_nlk_portid)))
> + pr_warn("auditd replaced by new
> auditd before normal shutdown: "
> + "(old)audit_pid=%d
> (by)pid=%d new_pid=%d",
> + audit_pid, pid, new_pid);
> if ((!new_pid) && (task_tgid_vnr(current) !=
> audit_pid))
> return -EACCES;
> if (audit_enabled != AUDIT_OFF)
^ permalink raw reply
* Re: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd
From: Richard Guy Briggs @ 2015-09-07 16:58 UTC (permalink / raw)
To: linux-audit, linux-kernel; +Cc: v.rathor
In-Reply-To: <5e786f07b6d8a19927c70345c14bd1a452164d38.1441644314.git.rgb@redhat.com>
On 15/09/07, Richard Guy Briggs wrote:
> Nothing prevents a new auditd starting up and replacing a valid
> audit_pid when an old auditd is still running, effectively starving out
> the old auditd since audit_pid no longer points to the old valid auditd.
>
> There isn't an easy way to detect if an old auditd is still running on
> the existing audit_pid other than attempting to send a message to see if
> it fails. If no message to auditd has been attempted since auditd died
> unnaturally or got killed, audit_pid will still indicate it is alive.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Ok, self-nack on this one for a couple of problems...
netlink_getsockbyportid() is static to af_netlink.c and "pid" should be
task_tgid_vnr(current). Otherwise, any opinions on this approach?
> ---
> Note: Would it be too bold to actually block the registration of a new
> auditd if the netlink_getsockbyportid() call succeeded? Would other
> checks be appropriate?
>
> kernel/audit.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 18cdfe2..1fa1e0d 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -872,6 +872,11 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
> if (s.mask & AUDIT_STATUS_PID) {
> int new_pid = s.pid;
>
> + if (audit_pid && new_pid &&
> + !IS_ERR(netlink_getsockbyportid(audit_sock, audit_nlk_portid)))
> + pr_warn("auditd replaced by new auditd before normal shutdown: "
> + "(old)audit_pid=%d (by)pid=%d new_pid=%d",
> + audit_pid, pid, new_pid);
> if ((!new_pid) && (task_tgid_vnr(current) != audit_pid))
> return -EACCES;
> if (audit_enabled != AUDIT_OFF)
> --
> 1.7.1
>
- 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
^ permalink raw reply
* [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd
From: Richard Guy Briggs @ 2015-09-07 16:48 UTC (permalink / raw)
To: linux-audit, linux-kernel
Cc: Richard Guy Briggs, sgrubb, pmoore, eparis, v.rathor, ctcard
Nothing prevents a new auditd starting up and replacing a valid
audit_pid when an old auditd is still running, effectively starving out
the old auditd since audit_pid no longer points to the old valid auditd.
There isn't an easy way to detect if an old auditd is still running on
the existing audit_pid other than attempting to send a message to see if
it fails. If no message to auditd has been attempted since auditd died
unnaturally or got killed, audit_pid will still indicate it is alive.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
Note: Would it be too bold to actually block the registration of a new
auditd if the netlink_getsockbyportid() call succeeded? Would other
checks be appropriate?
kernel/audit.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 18cdfe2..1fa1e0d 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -872,6 +872,11 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
if (s.mask & AUDIT_STATUS_PID) {
int new_pid = s.pid;
+ if (audit_pid && new_pid &&
+ !IS_ERR(netlink_getsockbyportid(audit_sock, audit_nlk_portid)))
+ pr_warn("auditd replaced by new auditd before normal shutdown: "
+ "(old)audit_pid=%d (by)pid=%d new_pid=%d",
+ audit_pid, pid, new_pid);
if ((!new_pid) && (task_tgid_vnr(current) != audit_pid))
return -EACCES;
if (audit_enabled != AUDIT_OFF)
--
1.7.1
^ permalink raw reply related
* [PATCH V2] audit: try harder to send to auditd upon netlink failure
From: Richard Guy Briggs @ 2015-09-07 9:10 UTC (permalink / raw)
To: linux-audit, linux-kernel
Cc: Richard Guy Briggs, sgrubb, pmoore, eparis, v.rathor, ctcard
There are several reports of the kernel losing contact with auditd when
it is, in fact, still running. When this happens, kernel syslogs show:
"audit: *NO* daemon at audit_pid=<pid>"
although auditd is still running, and is apparently happy, listening on
the netlink socket. The pid in the "*NO* daemon" message matches the pid
of the running auditd process. Restarting auditd solves this.
The problem appears to happen randomly, and doesn't seem to be strongly
correlated to the rate of audit events being logged. The problem
happens fairly regularly (every few days), but not yet reproduced to
order.
On production kernels, BUG_ON() is a no-op, so any error will trigger
this.
Commit 34eab0a7cd45 ("audit: prevent an older auditd shutdown from
orphaning a newer auditd startup") eliminates one possible cause. This
isn't the case here, since the PID in the error message and the PID of
the running auditd match.
The primary expected cause of error here is -ECONNREFUSED when the audit
daemon goes away, when netlink_getsockbyportid() can't find the auditd
portid entry in the netlink audit table (or there is no receive
function). If -EPERM is returned, that situation isn't likely to be
resolved in a timely fashion without administrator intervention. In
both cases, reset the audit_pid. This does not rule out a race
condition. SELinux is expected to return zero since this isn't an INET
or INET6 socket. Other LSMs may have other return codes. Log the error
code for better diagnosis in the future.
In the case of -ENOMEM, the situation could be temporary, based on local
or general availability of buffers. -EAGAIN should never happen since
the netlink audit (kernel) socket is set to MAX_SCHEDULE_TIMEOUT.
-ERESTARTSYS and -EINTR are not expected since this kernel thread is not
expected to receive signals. In these cases (or any other unexpected
ones for now), report the error and re-schedule the thread, retrying up
to 5 times.
v2:
Removed BUG_ON().
Moved comma in pr_*() statements.
Removed audit_strerror() text.
Reported-by: Vipin Rathor <v.rathor@gmail.com>
Reported-by: <ctcard@hotmail.com>
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
kernel/audit.c | 24 +++++++++++++++++++-----
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 1c13e42..18cdfe2 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -407,16 +407,30 @@ static void audit_printk_skb(struct sk_buff *skb)
static void kauditd_send_skb(struct sk_buff *skb)
{
int err;
+ int attempts = 0;
+#define AUDITD_RETRIES 5
+
+restart:
/* take a reference in case we can't send it and we want to hold it */
skb_get(skb);
err = netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
if (err < 0) {
- BUG_ON(err != -ECONNREFUSED); /* Shouldn't happen */
+ pr_err("netlink_unicast sending to audit_pid=%d returned error: %d\n",
+ audit_pid, err);
if (audit_pid) {
- pr_err("*NO* daemon at audit_pid=%d\n", audit_pid);
- audit_log_lost("auditd disappeared");
- audit_pid = 0;
- audit_sock = NULL;
+ if (err == -ECONNREFUSED || err == -EPERM
+ || ++attempts >= AUDITD_RETRIES) {
+ audit_log_lost("audit_pid=%d reset");
+ audit_pid = 0;
+ audit_sock = NULL;
+ } else {
+ pr_warn("re-scheduling(#%d) write to audit_pid=%d\n",
+ attempts, audit_pid);
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule();
+ __set_current_state(TASK_RUNNING);
+ goto restart;
+ }
}
/* we might get lucky and get this in the next auditd */
audit_hold_skb(skb);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH V1] audit: try harder to send to auditd upon netlink failure
From: Richard Guy Briggs @ 2015-09-07 7:16 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, linux-kernel, sgrubb, eparis, v.rathor, ctcard
In-Reply-To: <3789288.SQMGBHfSc0@sifl>
On 15/09/04, Paul Moore wrote:
> On Friday, September 04, 2015 05:14:54 AM Richard Guy Briggs wrote:
> > There are several reports of the kernel losing contact with auditd ...
>
> Even if this doesn't completely solve the problem, I like the extra reporting
> and robustness of this change. Some comments inline ...
>
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 1c13e42..4ee114a 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -404,19 +404,54 @@ static void audit_printk_skb(struct sk_buff *skb)
> > audit_hold_skb(skb);
> > }
> >
> > +static char *audit_strerror(int err)
> > +{
> > + switch (err) {
> > + case -ECONNREFUSED:
> > + return "ECONNREFUSED";
> > + case -EPERM:
> > + return "EPERM";
> > + case -ENOMEM:
> > + return "ENOMEM";
> > + case -EAGAIN:
> > + return "EAGAIN";
> > + case -ERESTARTSYS:
> > + return "ERESTARTSYS";
> > + case -EINTR:
> > + return "EINTR";
> > + default:
> > + return "(other)";
> > + }
> > +}
>
> See comments below.
>
> > static void kauditd_send_skb(struct sk_buff *skb)
> > {
> > int err;
> > + int attempts = 0;
> > +#define AUDITD_RETRIES 5
> > +
> > +restart:
> > /* take a reference in case we can't send it and we want to hold it */
> > skb_get(skb);
>
> Should the restart label go after the skb_get() call? It seems like if we
> ever jump to restart we could end up needlessly bumping the skb's refcnt.
I checked specifically for this and all the paths through
netlink_unicast() that return an error consume the skb. In fact, all
paths through netlink_unicast() consume the skb.
> > err = netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
> > if (err < 0) {
> > BUG_ON(err != -ECONNREFUSED); /* Shouldn't happen */
> > + pr_err("netlink_unicast sending to audit_pid=%d returned error: %d,
> %s\n"
> > + , audit_pid, err, audit_strerror(err));
>
> This is a style nit, but please put the comma on the preceding line. I know
> why you did it, but it bothers me.
I blame Hugh Redelmeier with whom I worked on the FreeS/WAN project, who
has been heavily involved with the ANSI C standards committee. ;-) I
should be sticking with the prevailing standard of the existing code.
> I'm also debating if audit_strerror() is worth it. I agree with you that it
> is a good idea to indicate the specific error code, I'm just not sure we need
> to bother translating that into a proper errno name. Can you think of some
> reason why we would need the errno name as opposed to the integer?
Other than convenience, not really. The only reason other than that
would be if an unexpected error code is returned it will be mover
obvious to me when reviewing a user report. Other than that, it is
complete without the text.
> > if (audit_pid) {
> > - pr_err("*NO* daemon at audit_pid=%d\n", audit_pid);
> > - audit_log_lost("auditd disappeared");
> > - audit_pid = 0;
> > - audit_sock = NULL;
> > + if (err == -ECONNREFUSED || err == -EPERM
> > + || ++attempts >= AUDITD_RETRIES) {
> > + audit_log_lost("audit_pid=%d reset");
> > + audit_pid = 0;
> > + audit_sock = NULL;
> > + } else {
> > + pr_warn("re-scheduling(#%d) write to audit_pid=%d\n"
> > + , attempts, audit_pid);
>
> Same thing with the comma.
>
> > + set_current_state(TASK_INTERRUPTIBLE);
> > + schedule();
> > + __set_current_state(TASK_RUNNING);
> > + goto restart;
>
> See my comment above about the skb's reference count.
>
> > + }
> > }
> > /* we might get lucky and get this in the next auditd */
> > audit_hold_skb(skb);
>
> --
> paul moore
> www.paul-moore.com
>
- 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
^ permalink raw reply
* Re: [PATCH V1] audit: try harder to send to auditd upon netlink failure
From: Paul Moore @ 2015-09-04 18:52 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: linux-audit, linux-kernel, sgrubb, eparis, v.rathor, ctcard
In-Reply-To: <30ca274fb2de087359d47808bda1ca1a6bb63392.1441349871.git.rgb@redhat.com>
On Friday, September 04, 2015 05:14:54 AM Richard Guy Briggs wrote:
> There are several reports of the kernel losing contact with auditd ...
Even if this doesn't completely solve the problem, I like the extra reporting
and robustness of this change. Some comments inline ...
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 1c13e42..4ee114a 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -404,19 +404,54 @@ static void audit_printk_skb(struct sk_buff *skb)
> audit_hold_skb(skb);
> }
>
> +static char *audit_strerror(int err)
> +{
> + switch (err) {
> + case -ECONNREFUSED:
> + return "ECONNREFUSED";
> + case -EPERM:
> + return "EPERM";
> + case -ENOMEM:
> + return "ENOMEM";
> + case -EAGAIN:
> + return "EAGAIN";
> + case -ERESTARTSYS:
> + return "ERESTARTSYS";
> + case -EINTR:
> + return "EINTR";
> + default:
> + return "(other)";
> + }
> +}
See comments below.
> static void kauditd_send_skb(struct sk_buff *skb)
> {
> int err;
> + int attempts = 0;
> +#define AUDITD_RETRIES 5
> +
> +restart:
> /* take a reference in case we can't send it and we want to hold it */
> skb_get(skb);
Should the restart label go after the skb_get() call? It seems like if we
ever jump to restart we could end up needlessly bumping the skb's refcnt.
> err = netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
> if (err < 0) {
> BUG_ON(err != -ECONNREFUSED); /* Shouldn't happen */
> + pr_err("netlink_unicast sending to audit_pid=%d returned error: %d,
%s\n"
> + , audit_pid, err, audit_strerror(err));
This is a style nit, but please put the comma on the preceding line. I know
why you did it, but it bothers me.
I'm also debating if audit_strerror() is worth it. I agree with you that it
is a good idea to indicate the specific error code, I'm just not sure we need
to bother translating that into a proper errno name. Can you think of some
reason why we would need the errno name as opposed to the integer?
> if (audit_pid) {
> - pr_err("*NO* daemon at audit_pid=%d\n", audit_pid);
> - audit_log_lost("auditd disappeared");
> - audit_pid = 0;
> - audit_sock = NULL;
> + if (err == -ECONNREFUSED || err == -EPERM
> + || ++attempts >= AUDITD_RETRIES) {
> + audit_log_lost("audit_pid=%d reset");
> + audit_pid = 0;
> + audit_sock = NULL;
> + } else {
> + pr_warn("re-scheduling(#%d) write to audit_pid=%d\n"
> + , attempts, audit_pid);
Same thing with the comma.
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule();
> + __set_current_state(TASK_RUNNING);
> + goto restart;
See my comment above about the skb's reference count.
> + }
> }
> /* we might get lucky and get this in the next auditd */
> audit_hold_skb(skb);
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: perhaps obvious question: auditd and setuid/setgid?
From: John Jasen @ 2015-09-04 17:36 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <2447871.tML4uAQppZ@x2>
On 09/04/2015 12:20 PM, Steve Grubb wrote:
> On Friday, September 04, 2015 10:54:47 AM John Jasen wrote:
>> I was specifically wondering if I was missing the appropriate syscall
>> for the use of setuid or setgid.
>>
> >From a brief examination and test, this appears to not be the case?
>
> There are a couple ways to do this. One is using the find method. However, that
> does not take into account file system based capabilities. In the lab I taught
> this week, the rules generator also included this:
<snipped> filecap examples to add LINUX_CAP executables to audit.rules.
Huh .... I did not think of that.
> But, if all you want is setuid, then you can use a rule like this instead of
> file watches:
>
> -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0
Perfect! Thanks.
For future generations googling for answers, I did the following:
-a always,exit -F arch=x86_64 -S execve -C uid!=euid -F key=execpriv
-a always,exit -F arch=x86_64 -S execve -C gid!=egid -F key=execpriv
I didn't pursue the last match, -F euid=0, as there may be cases where
you wish to audit setuid usage, but the binary is not setuid to root.
^ permalink raw reply
* Re: perhaps obvious question: auditd and setuid/setgid?
From: Steve Grubb @ 2015-09-04 16:20 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <55E9B0B7.9040607@gmail.com>
On Friday, September 04, 2015 10:54:47 AM John Jasen wrote:
> I was specifically wondering if I was missing the appropriate syscall
> for the use of setuid or setgid.
>
>From a brief examination and test, this appears to not be the case?
There are a couple ways to do this. One is using the find method. However, that
does not take into account file system based capabilities. In the lab I taught
this week, the rules generator also included this:
filecap /bin 2>/dev/null | awk '{ printf "-a always,exit -F path=%s -F perm=x -
F auid>=1000 -F auid!=4294967295 -F key=privileged\n", $1 }' >> priv.rules
filecap /sbin 2>/dev/null | awk '{ printf "-a always,exit -F path=%s -F perm=x
-F auid>=1000 -F auid!=4294967295 -F key=privileged\n", $1 }' >> priv.rules
filecap /usr/bin 2>/dev/null | awk '{ printf "-a always,exit -F path=%s -F
perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged\n", $1 }' >>
priv.rules
filecap /usr/sbin 2>/dev/null | awk '{ printf "-a always,exit -F path=%s -F
perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged\n", $1 }' >>
priv.rules
But, if all you want is setuid, then you can use a rule like this instead of
file watches:
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0
-Steve
> On 09/02/2015 10:32 PM, rshaw1@umbc.edu wrote:
> >> I'm currently testing auditd with rules for setuid or setgid binaries on
> >> the system.
> >>
> >> I currently maintain the list via find, and pushing the results to a
> >> audit.rules file.
> >>
> >> I'm hoping there's a cleaner way, perhaps by triggering on the
> >> appropriate syscall -- but have not discovered it.
> >>
> >> Is there an easier method?
> >
> > The find method is what I use (though I push it to a file in rules.d and
> > then run augenrules, which for RHEL5/6 I just stole from RHEL7). Using
> > find to generate these rules is actually in the text of, IIRC, at least
> > one of the RHEL STIGs (6, draft of 7, possibly both), though not quite as
> > automated as the way I do it.
> >
> > --Ray
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: perhaps obvious question: auditd and setuid/setgid?
From: John Jasen @ 2015-09-04 14:54 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <cf862b019d9d310f8c605a804d778428.squirrel@webmail.umbc.edu>
I was specifically wondering if I was missing the appropriate syscall
for the use of setuid or setgid.
>From a brief examination and test, this appears to not be the case?
On 09/02/2015 10:32 PM, rshaw1@umbc.edu wrote:
>> I'm currently testing auditd with rules for setuid or setgid binaries on
>> the system.
>>
>> I currently maintain the list via find, and pushing the results to a
>> audit.rules file.
>>
>> I'm hoping there's a cleaner way, perhaps by triggering on the
>> appropriate syscall -- but have not discovered it.
>>
>> Is there an easier method?
> The find method is what I use (though I push it to a file in rules.d and
> then run augenrules, which for RHEL5/6 I just stole from RHEL7). Using
> find to generate these rules is actually in the text of, IIRC, at least
> one of the RHEL STIGs (6, draft of 7, possibly both), though not quite as
> automated as the way I do it.
>
> --Ray
>
^ permalink raw reply
* [PATCH V1] audit: try harder to send to auditd upon netlink failure
From: Richard Guy Briggs @ 2015-09-04 9:14 UTC (permalink / raw)
To: linux-audit, linux-kernel
Cc: Richard Guy Briggs, sgrubb, pmoore, eparis, v.rathor, ctcard
There are several reports of the kernel losing contact with auditd when it is,
in fact, still running. When this happens, kernel syslogs show:
"audit: *NO* daemon at audit_pid=<pid>"
although auditd is still running, and is apparently happy, listening on the
netlink socket. The pid in the "*NO* daemon" message matches the pid of the
running auditd process. Restarting auditd solves this.
The problem appears to happen randomly, and doesn't seem to be strongly
correlated to the rate of audit events being logged. The problem happens
fairly regularly (every few days), but not yet reproduced to order.
On production kernels, BUG_ON() is a no-op, so any error will trigger this.
Commit 34eab0a7 eliminates one possible cause. This isn't the case here, since
the PID in the error message and the PID of the running auditd match.
The primary expected cause of error here is -ECONNREFUSED when the audit daemon
goes away, when netlink_getsockbyportid() can't find the auditd portid entry in
the netlink audit table (or there is no receive function). If -EPERM is
returned, that situation isn't likely to be resolved in a timely fashion
without administrator intervention. In both cases, reset the audit_pid. This
does not rule out a race condition. SELinux is expected to return zero since
this isn't an INET or INET6 socket. Other LSMs may have other return codes.
Log the error code for better diagnosis in the future.
In the case of -ENOMEM, the situation could be temporary, based on local or
general availability of buffers. -EAGAIN should never happen since the netlink
audit (kernel) socket is set to MAX_SCHEDULE_TIMEOUT. -ERESTARTSYS and -EINTR
are not expected since this kernel thread is not expected to receive signals.
In these cases (or any other unexpected ones for now), report the error and
re-schedule the thread, retrying up to 5 times.
Reported-by: Vipin Rathor <v.rathor@gmail.com>
Reported-by: <ctcard@hotmail.com>
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
kernel/audit.c | 43 +++++++++++++++++++++++++++++++++++++++----
1 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 1c13e42..4ee114a 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -404,19 +404,54 @@ static void audit_printk_skb(struct sk_buff *skb)
audit_hold_skb(skb);
}
+static char *audit_strerror(int err)
+{
+ switch (err) {
+ case -ECONNREFUSED:
+ return "ECONNREFUSED";
+ case -EPERM:
+ return "EPERM";
+ case -ENOMEM:
+ return "ENOMEM";
+ case -EAGAIN:
+ return "EAGAIN";
+ case -ERESTARTSYS:
+ return "ERESTARTSYS";
+ case -EINTR:
+ return "EINTR";
+ default:
+ return "(other)";
+ }
+}
+
static void kauditd_send_skb(struct sk_buff *skb)
{
int err;
+ int attempts = 0;
+#define AUDITD_RETRIES 5
+
+restart:
/* take a reference in case we can't send it and we want to hold it */
skb_get(skb);
err = netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
if (err < 0) {
BUG_ON(err != -ECONNREFUSED); /* Shouldn't happen */
+ pr_err("netlink_unicast sending to audit_pid=%d returned error: %d, %s\n"
+ , audit_pid, err, audit_strerror(err));
if (audit_pid) {
- pr_err("*NO* daemon at audit_pid=%d\n", audit_pid);
- audit_log_lost("auditd disappeared");
- audit_pid = 0;
- audit_sock = NULL;
+ if (err == -ECONNREFUSED || err == -EPERM
+ || ++attempts >= AUDITD_RETRIES) {
+ audit_log_lost("audit_pid=%d reset");
+ audit_pid = 0;
+ audit_sock = NULL;
+ } else {
+ pr_warn("re-scheduling(#%d) write to audit_pid=%d\n"
+ , attempts, audit_pid);
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule();
+ __set_current_state(TASK_RUNNING);
+ goto restart;
+ }
}
/* we might get lucky and get this in the next auditd */
audit_hold_skb(skb);
--
1.7.1
^ permalink raw reply related
* [GIT PULL] Audit patches for 4.3
From: Paul Moore @ 2015-09-03 20:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-audit, linux-kernel
Hi Linus,
This is one of the larger audit patchsets in recent history, consisting of
eight patches and almost 400 lines of changes. The bulk of the patchset is
the new "audit by executable" functionality which allows admins to set an
audit watch based on the executable on disk. Prior to this, admins could only
track an application by PID, which has some obvious limitations. Beyond the
new functionality we also have some refcnt fixes and a few minor cleanups.
Please pull for 4.3.
Thanks,
-Paul
---
The following changes since commit 0b08c5e59441d08ab4b5e72afefd5cd98a4d83df:
audit: Fix check of return value of strnlen_user()
(2015-06-11 15:49:54 -0400)
are available in the git repository at:
git://git.infradead.org/users/pcmoore/audit upstream
for you to fetch changes up to 15ce414b82b07acb99afda6e4d9bd14f317b6011:
fixup: audit: implement audit by executable (2015-08-12 22:04:07 -0400)
----------------------------------------------------------------
Paul Moore (1):
audit: fix uninitialized variable in audit_add_rule()
Richard Guy Briggs (7):
audit: eliminate unnecessary extra layer of watch references
audit: eliminate unnecessary extra layer of watch parent references
audit: make audit_del_rule() more robust
audit: use macros for unset inode and device values
audit: clean simple fsnotify implementation
audit: implement audit by executable
fixup: audit: implement audit by executable
include/linux/audit.h | 4 +
include/uapi/linux/audit.h | 5 +-
kernel/Makefile | 2 +-
kernel/audit.c | 2 +-
kernel/audit.h | 18 ++++
kernel/audit_fsnotify.c | 216 ++++++++++++++++++++++++++++++++++++++++++
kernel/audit_tree.c | 2 +
kernel/audit_watch.c | 56 +++++++++---
kernel/auditfilter.c | 83 ++++++++++++-----
kernel/auditsc.c | 9 +-
10 files changed, 359 insertions(+), 38 deletions(-)
create mode 100644 kernel/audit_fsnotify.c
--
paul moore
security @ redhat
^ permalink raw reply
* Re: Monitoring of linux containers
From: Richard Guy Briggs @ 2015-09-03 5:38 UTC (permalink / raw)
To: Roi Martin; +Cc: linux-audit
In-Reply-To: <CAK-N_m9askC0ytS=WwutYRGb5PD_esjxw6CncoMip90PsLGRdw@mail.gmail.com>
On 15/09/02, Roi Martin wrote:
> Hello,
Hi Roi,
> First, let me give you a bit of context about what we are trying to do.
> Basically, we are working on a monitoring solution for linux containers
> based on audit. The idea is logging all the syscalls executed within
> certain container and take metrics, that are compared with a baseline in
> order to find anomalies on the executed services. For instance, take as
> example a micro-service running within a container, if suddenly we see a
> clone, followed by an execve of "/bin/sh", this should be detected and
> actions would be taken automatically.
>
> The thing is that to accomplish this, we need to create an audit rule that
> allows to filter only those system calls executed in the context of the
> monitored containers. For this, I can think on two possible ways:
> 1. By PID: Creating a rule like "filter all the syscalls executed by the
> process with PID X and all its current and future children".
A general problem with filtering on PID X is that currently is keyed on
a number, which can roll. Reaping the rule when that process terminates
(and all its children) might be one way to do it, but that is not
currently implemented.
> 2. By namespace: It would be great to be able to create a rule that filters
> all the syscalls executed under a given list of namespaces, in this case,
> those corresponding to the monitored container.
Agreed! A number of people have been thinking about this problem. The
problem is how to define a container and how to track a namespace.
There have been a number of patches submitted in the last couple of
years to try to address this, but discussion and development are still
on-going.
> But, after reading the audit's documentation, looks like right now any of
> these options are supported without applying some unofficial patch.
>
> A work-around would be to automatically add a new rule per new child, but
> the new processes wouldn't be monitoring the time since its start until the
> creation the rule, causing race conditions (creation of a new child, that
> would not be detected, etc.)
>
> Are you aware of some other option that would allow what we need?
Not yet, but that problem definitely needs to be solved, so please keep
the conversation going.
One goal is to be able to run an audit daemon in a container, isolated
from the master audit daemon on the system. It would be able to monitor
activity in that container and any other containers spawned by it, but
not be able to change the configuration of any that are containing it.
> Thanks in advance.
>
> Regards,
> Roi
> --
> 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
^ permalink raw reply
* Monitoring of linux containers
From: Roi Martin @ 2015-09-02 21:46 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 1592 bytes --]
Hello,
First, let me give you a bit of context about what we are trying to do.
Basically, we are working on a monitoring solution for linux containers
based on audit. The idea is logging all the syscalls executed within
certain container and take metrics, that are compared with a baseline in
order to find anomalies on the executed services. For instance, take as
example a micro-service running within a container, if suddenly we see a
clone, followed by an execve of "/bin/sh", this should be detected and
actions would be taken automatically.
The thing is that to accomplish this, we need to create an audit rule that
allows to filter only those system calls executed in the context of the
monitored containers. For this, I can think on two possible ways:
1. By PID: Creating a rule like "filter all the syscalls executed by the
process with PID X and all its current and future children".
2. By namespace: It would be great to be able to create a rule that filters
all the syscalls executed under a given list of namespaces, in this case,
those corresponding to the monitored container.
But, after reading the audit's documentation, looks like right now any of
these options are supported without applying some unofficial patch.
A work-around would be to automatically add a new rule per new child, but
the new processes wouldn't be monitoring the time since its start until the
creation the rule, causing race conditions (creation of a new child, that
would not be detected, etc.)
Are you aware of some other option that would allow what we need?
Thanks in advance.
Regards,
Roi
[-- Attachment #1.2: Type: text/html, Size: 2527 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: perhaps obvious question: auditd and setuid/setgid?
From: rshaw1 @ 2015-09-03 2:32 UTC (permalink / raw)
To: John Jasen; +Cc: linux-audit
In-Reply-To: <55E780DE.80400@gmail.com>
> I'm currently testing auditd with rules for setuid or setgid binaries on
> the system.
>
> I currently maintain the list via find, and pushing the results to a
> audit.rules file.
>
> I'm hoping there's a cleaner way, perhaps by triggering on the
> appropriate syscall -- but have not discovered it.
>
> Is there an easier method?
The find method is what I use (though I push it to a file in rules.d and
then run augenrules, which for RHEL5/6 I just stole from RHEL7). Using
find to generate these rules is actually in the text of, IIRC, at least
one of the RHEL STIGs (6, draft of 7, possibly both), though not quite as
automated as the way I do it.
--Ray
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox