From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Cc: rgb@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, ebiederm@xmission.com,
akpm@linux-foundation.org, David Miller <davem@davemloft.net>
Subject: Re: [RFC][PATCH] audit: Simplify by assuming the callers socket buffer is large enough
Date: Wed, 05 Mar 2014 11:59:01 -0500 [thread overview]
Message-ID: <7457128.6VP2v68V93@x2> (raw)
In-Reply-To: <20140304.192152.1234652192226780071.davem@davemloft.net>
On Tuesday, March 04, 2014 07:21:52 PM David Miller wrote:
> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Tue, 04 Mar 2014 14:41:16 -0800
>
> > If we really want the ability to always appened to the queue of skb's
> > is to just have a version of netlink_send_skb that ignores the queued
> > limits. Of course an evil program then could force the generation of
> > enough audit records to DOS the kernel, but we seem to be in that
> > situation now. Shrug.
>
> There is never a valid reason to bypass the socket limits.
>
> It protects the system from things going out of control.
>
> Netlink packet sends can fail, and audit should cope with that
> event instead of trying to bludgeon it into not happening.
I am not sure what exactly is the problem with the code that was being
patched. The audit code has been stable and working pretty well for everyone
for the last 5-6 years. But lately there has been a lot of kernel code churn
and I am concerned that the changes are being made without a complete
understanding of the design goals.
The audit system has to be very reliable. It can't lose any event or record.
The people that really depend on it would rather have access denied to the
system than lose any event. This is the reason it goes to such lengths.
If I understand the patch, it looks like its affecting code that adds, deletes,
or lists audit rules. This code is quite old and working well. It didn't at
first. We found a lot of problems by writing scripts like:
#!/bin/bash
while [ 1 ] ;
do
echo "Inserting syscalls..."
sys=1
while [ $sys -lt 100 ]
do
sys=`expr $sys + 1`
echo "$sys"
auditctl -a entry,always -S $sys
done
echo "Listing..."
auditctl -l
echo "Deleting..."
auditctl -D
done
with another shell running:
#!/bin/bash
while [ 1 ] ;
do
echo "Listing..."
auditctl -l
done
and another shell running:
#!/bin/bash
while [ 1 ] ;
do
echo "Disabling..."
auditctl -e 0
echo "Enabling..."
auditctl -e 1
done
You can probably imagine more stress tests. But the proposed code should be
well tested similar to this.
Thanks,
-Steve
next prev parent reply other threads:[~2014-03-05 16:59 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-28 18:49 [PATCH] audit: Use struct net not pid_t to remember the network namespce to reply in Eric W. Biederman
2014-03-01 1:11 ` Richard Guy Briggs
2014-03-01 4:34 ` Eric W. Biederman
2014-03-01 4:36 ` [PATCH] audit: Send replies in the proper network namespace Eric W. Biederman
2014-03-01 4:50 ` [RFC][PATCH] audit: Simplify by assuming the callers socket buffer is large enough Eric W. Biederman
2014-03-04 21:30 ` Andrew Morton
2014-03-04 21:51 ` David Miller
2014-03-04 22:41 ` Eric W. Biederman
2014-03-04 22:50 ` Andrew Morton
2014-03-10 3:06 ` [GIT PULL] namespaces fixes for 3.14-rcX Eric W. Biederman
2014-03-10 13:59 ` Eric Paris
2014-03-10 19:56 ` Eric W. Biederman
2014-03-16 18:36 ` Richard Guy Briggs
2014-03-05 0:21 ` [RFC][PATCH] audit: Simplify by assuming the callers socket buffer is large enough David Miller
2014-03-05 16:59 ` Steve Grubb [this message]
2014-03-05 17:57 ` LC Bruzenak
2014-03-05 18:06 ` Eric W. Biederman
2014-03-07 22:52 ` Eric Paris
2014-03-08 0:48 ` David Miller
2014-03-08 3:27 ` Steve Grubb
2014-03-08 6:34 ` David Miller
2014-03-08 3:56 ` Eric Paris
2014-03-10 19:30 ` David Miller
2014-03-10 21:57 ` Eric Paris
2014-03-16 18:19 ` [PATCH] audit: Send replies in the proper network namespace Richard Guy Briggs
2014-03-16 19:13 ` Richard Guy Briggs
2014-03-16 18:15 ` [PATCH] audit: Use struct net not pid_t to remember the network namespce to reply in Richard Guy Briggs
2014-03-16 19:12 ` Richard Guy Briggs
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=7457128.6VP2v68V93@x2 \
--to=sgrubb@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=linux-audit@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).