* Re: [PATCH] fixup! audit: try harder to send to auditd upon netlink failure
From: Paul Moore @ 2015-09-22 22:32 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: linux-audit, linux-kernel, sgrubb, eparis, v.rathor, ctcard
In-Reply-To: <b3c5c9441c3d461465a9686388e8baba2ae2449f.1442699085.git.rgb@redhat.com>
On Saturday, September 19, 2015 05:52:50 PM Richard Guy Briggs wrote:
> A bug was introduced by "audit: try harder to send to auditd upon
> netlink failure", caused by incomplete code and a function that expects
> a string and does not accept a format plus arguments. Create a
> temporary string variable to assemble the output text. It could be
> merged as a fixup if it is not yet upstream.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/audit.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
Applied and both patches squashed into one.
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 18cdfe2..9d32218 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -420,7 +420,10 @@ restart:
> if (audit_pid) {
> if (err == -ECONNREFUSED || err == -EPERM
>
> || ++attempts >= AUDITD_RETRIES) {
>
> - audit_log_lost("audit_pid=%d reset");
> + char s[32];
> +
> + snprintf(s, sizeof(s), "audit_pid=%d reset", audit_pid);
> + audit_log_lost(s);
> audit_pid = 0;
> audit_sock = NULL;
> } else {
--
paul moore
security @ redhat
^ permalink raw reply
* [PATCH] fixup! audit: try harder to send to auditd upon netlink failure
From: Richard Guy Briggs @ 2015-09-19 21:52 UTC (permalink / raw)
To: linux-audit, linux-kernel
Cc: Richard Guy Briggs, sgrubb, pmoore, eparis, v.rathor, ctcard
A bug was introduced by "audit: try harder to send to auditd upon
netlink failure", caused by incomplete code and a function that expects
a string and does not accept a format plus arguments. Create a
temporary string variable to assemble the output text. It could be
merged as a fixup if it is not yet upstream.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
kernel/audit.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 18cdfe2..9d32218 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -420,7 +420,10 @@ restart:
if (audit_pid) {
if (err == -ECONNREFUSED || err == -EPERM
|| ++attempts >= AUDITD_RETRIES) {
- audit_log_lost("audit_pid=%d reset");
+ char s[32];
+
+ snprintf(s, sizeof(s), "audit_pid=%d reset", audit_pid);
+ audit_log_lost(s);
audit_pid = 0;
audit_sock = NULL;
} else {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] fixup! audit: try harder to send to auditd upon netlink failure
From: Richard Guy Briggs @ 2015-09-19 21:52 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, linux-kernel, sgrubb, eparis, v.rathor, ctcard
In-Reply-To: <1569995.Ps6FDGqW2H@sifl>
On 15/09/18, Paul Moore wrote:
> On Friday, September 18, 2015 03:52:43 AM Richard Guy Briggs wrote:
> > A bug was introduced by "audit: try harder to send to auditd upon
> > netlink failure", caused by incomplete code and a function that expects
> > a string and does not accept a format plus arguments. Create a
> > temporary string variable to assemble the output text. It could be
> > merged as a fixup if it is not yet upstream.
>
> Ungh, that's embarrassing; I really should have caught that in review. Sigh.
> At least it shouldn't cause anything to blow up, just a less than helpful
> message.
Yup, just useless noise.
> I pulled the original patch from linux-audit#next just now, I'll re-add it
> once we sort this out.
Ok...
> Comments below ...
Likewise...
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > kernel/audit.c | 5 ++++-
> > 1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 18cdfe2..60913e6 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -420,7 +420,10 @@ restart:
> > if (audit_pid) {
> > if (err == -ECONNREFUSED || err == -EPERM
> >
> > || ++attempts >= AUDITD_RETRIES) {
> >
> > - audit_log_lost("audit_pid=%d reset");
> > + char s[32];
> > +
> > + sprintf(s, "audit_pid=%d reset", audit_pid);
> > + audit_log_lost(s);
>
> Granted 32 bytes should be big enough for the string, but I would feel better
> if we used snprintf() here; make the change and I'll merge the patch with the
> original and push it back to linux-audit#next.
Done...
> Normally I'm not a big fan of amending patches after they have been committed,
> but in this case it is in the next branch (doing this for upstream or stable-X
> is a big "no") and nothing sits on top of it.
That's the only reason I suggested it...
> > audit_pid = 0;
> > audit_sock = NULL;
> > } else {
>
> 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: [PATCH] fixup! audit: try harder to send to auditd upon netlink failure
From: Paul Moore @ 2015-09-18 20:33 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: linux-audit, linux-kernel, sgrubb, eparis, v.rathor, ctcard
In-Reply-To: <89a693758cd8f511892fe54c2e4aaf2cfca89e89.1442562580.git.rgb@redhat.com>
On Friday, September 18, 2015 03:52:43 AM Richard Guy Briggs wrote:
> A bug was introduced by "audit: try harder to send to auditd upon
> netlink failure", caused by incomplete code and a function that expects
> a string and does not accept a format plus arguments. Create a
> temporary string variable to assemble the output text. It could be
> merged as a fixup if it is not yet upstream.
Ungh, that's embarrassing; I really should have caught that in review. Sigh.
At least it shouldn't cause anything to blow up, just a less than helpful
message.
I pulled the original patch from linux-audit#next just now, I'll re-add it
once we sort this out.
Comments below ...
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/audit.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 18cdfe2..60913e6 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -420,7 +420,10 @@ restart:
> if (audit_pid) {
> if (err == -ECONNREFUSED || err == -EPERM
>
> || ++attempts >= AUDITD_RETRIES) {
>
> - audit_log_lost("audit_pid=%d reset");
> + char s[32];
> +
> + sprintf(s, "audit_pid=%d reset", audit_pid);
> + audit_log_lost(s);
Granted 32 bytes should be big enough for the string, but I would feel better
if we used snprintf() here; make the change and I'll merge the patch with the
original and push it back to linux-audit#next.
Normally I'm not a big fan of amending patches after they have been committed,
but in this case it is in the next branch (doing this for upstream or stable-X
is a big "no") and nothing sits on top of it.
> audit_pid = 0;
> audit_sock = NULL;
> } else {
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCH] fixup! audit: try harder to send to auditd upon netlink failure
From: Richard Guy Briggs @ 2015-09-18 10:02 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit, linux-kernel, pmoore, eparis, v.rathor, ctcard
In-Reply-To: <20150918101341.205b02b4@ivy-bridge>
On 15/09/18, Steve Grubb wrote:
> On Fri, 18 Sep 2015 03:52:43 -0400
> Richard Guy Briggs <rgb@redhat.com> wrote:
>
> > A bug was introduced by "audit: try harder to send to auditd upon
> > netlink failure", caused by incomplete code and a function that
> > expects a string and does not accept a format plus arguments. Create
> > a temporary string variable to assemble the output text. It could be
> > merged as a fixup if it is not yet upstream.
> >
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > kernel/audit.c | 5 ++++-
> > 1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 18cdfe2..60913e6 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -420,7 +420,10 @@ restart:
> > if (audit_pid) {
> > if (err == -ECONNREFUSED || err == -EPERM
> > || ++attempts >= AUDITD_RETRIES) {
> > - audit_log_lost("audit_pid=%d reset");
> > + char s[32];
> > +
> > + sprintf(s, "audit_pid=%d reset",
> > audit_pid);
>
> We normally use name=value for everything important. Reset by itself
> will get dropped by auparse. action=reset (or something similar) would
> be better.
This is sent to the system log when we can't queue it to audit, so audit
never sees this message. None of the other audit_log_lost messages are
formatted in the audit style.
> -Steve
>
> > + audit_log_lost(s);
> > audit_pid = 0;
> > audit_sock = NULL;
> > } else {
>
- 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] fixup! audit: try harder to send to auditd upon netlink failure
From: Steve Grubb @ 2015-09-18 9:13 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: linux-audit, linux-kernel, pmoore, eparis, v.rathor, ctcard
In-Reply-To: <89a693758cd8f511892fe54c2e4aaf2cfca89e89.1442562580.git.rgb@redhat.com>
On Fri, 18 Sep 2015 03:52:43 -0400
Richard Guy Briggs <rgb@redhat.com> wrote:
> A bug was introduced by "audit: try harder to send to auditd upon
> netlink failure", caused by incomplete code and a function that
> expects a string and does not accept a format plus arguments. Create
> a temporary string variable to assemble the output text. It could be
> merged as a fixup if it is not yet upstream.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/audit.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 18cdfe2..60913e6 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -420,7 +420,10 @@ restart:
> if (audit_pid) {
> if (err == -ECONNREFUSED || err == -EPERM
> || ++attempts >= AUDITD_RETRIES) {
> - audit_log_lost("audit_pid=%d reset");
> + char s[32];
> +
> + sprintf(s, "audit_pid=%d reset",
> audit_pid);
We normally use name=value for everything important. Reset by itself
will get dropped by auparse. action=reset (or something similar) would
be better.
-Steve
> + audit_log_lost(s);
> audit_pid = 0;
> audit_sock = NULL;
> } else {
^ permalink raw reply
* [PATCH 2/2] audit: log failed attempts to change audit_pid configuration
From: Richard Guy Briggs @ 2015-09-18 7:59 UTC (permalink / raw)
To: linux-audit, linux-kernel
Cc: Richard Guy Briggs, sgrubb, pmoore, eparis, v.rathor, ctcard
In-Reply-To: <206b0f415832c9fde6befaa13a7b6efe916d1ba4.1442494593.git.rgb@redhat.com>
Failed attempts to change the audit_pid configuration are not presently
logged. One case is an attempt to starve an old auditd by starting up a
new auditd when the old one is still alive and active. The other case
is an attempt to orphan a new auditd when an old auditd shuts down.
Log both as AUDIT_CONFIG_CHANGE messages with failure result.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
kernel/audit.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 3399ab2..65dcd45 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -883,12 +883,16 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
pid_t requesting_pid = task_tgid_vnr(current);
u32 portid = NETLINK_CB(skb).portid;
- if ((!new_pid) && (requesting_pid != audit_pid))
+ if ((!new_pid) && (requesting_pid != audit_pid)) {
+ audit_log_config_change("audit_pid", new_pid, audit_pid, 0);
return -EACCES;
+ }
if (audit_pid && new_pid &&
audit_ping(requesting_pid, nlmsg_hdr(skb)->nlmsg_seq, portid) !=
- -ECONNREFUSED)
+ -ECONNREFUSED) {
+ audit_log_config_change("audit_pid", new_pid, audit_pid, 0);
return -EEXIST;
+ }
if (audit_enabled != AUDIT_OFF)
audit_log_config_change("audit_pid", new_pid, audit_pid, 1);
audit_pid = new_pid;
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] audit: stop an old auditd being starved out by a new auditd
From: Richard Guy Briggs @ 2015-09-18 7:59 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.
If no message to auditd has been attempted since auditd died unnaturally
or got killed, audit_pid will still indicate it is alive. 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.
An -ECONNREFUSED almost certainly means it disappeared and can be
replaced. Other errors are not so straightforward and may indicate
transient problems that will resolve themselves and the old auditd will
recover. Yet others will likely need manual intervention for which a
new auditd will not solve the problem.
Send a new message type (AUDIT_PING) to the old auditd containing a u32
with the PID of the new auditd. If the audit ping succeeds (or doesn't
fail with certainty), fail to register the new auditd and return an
error (-EEXIST).
This is expected to make the patch preventing an old auditd orphaning a
new auditd redundant.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
include/uapi/linux/audit.h | 1 +
kernel/audit.c | 19 +++++++++++++++++--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index d3475e1..4c97e30 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -70,6 +70,7 @@
#define AUDIT_TTY_SET 1017 /* Set TTY auditing status */
#define AUDIT_SET_FEATURE 1018 /* Turn an audit feature on or off */
#define AUDIT_GET_FEATURE 1019 /* Get which features are enabled */
+#define AUDIT_PING 1020 /* Ping auditd to see if it is alive */
#define AUDIT_FIRST_USER_MSG 1100 /* Userspace messages mostly uninteresting to kernel */
#define AUDIT_USER_AVC 1107 /* We filter this differently */
diff --git a/kernel/audit.c b/kernel/audit.c
index 18cdfe2..3399ab2 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -810,6 +810,15 @@ static int audit_set_feature(struct sk_buff *skb)
return 0;
}
+static int audit_ping(pid_t pid, u32 seq, u32 portid)
+{
+ struct sk_buff *skb = audit_make_reply(portid, seq, AUDIT_PING, 0, 0, &pid, sizeof(pid));
+
+ if (!skb)
+ return -ENOMEM;
+ return netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
+}
+
static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
{
u32 seq;
@@ -871,13 +880,19 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
}
if (s.mask & AUDIT_STATUS_PID) {
int new_pid = s.pid;
+ pid_t requesting_pid = task_tgid_vnr(current);
+ u32 portid = NETLINK_CB(skb).portid;
- if ((!new_pid) && (task_tgid_vnr(current) != audit_pid))
+ if ((!new_pid) && (requesting_pid != audit_pid))
return -EACCES;
+ if (audit_pid && new_pid &&
+ audit_ping(requesting_pid, nlmsg_hdr(skb)->nlmsg_seq, portid) !=
+ -ECONNREFUSED)
+ return -EEXIST;
if (audit_enabled != AUDIT_OFF)
audit_log_config_change("audit_pid", new_pid, audit_pid, 1);
audit_pid = new_pid;
- audit_nlk_portid = NETLINK_CB(skb).portid;
+ audit_nlk_portid = portid;
audit_sock = skb->sk;
}
if (s.mask & AUDIT_STATUS_RATE_LIMIT) {
--
1.7.1
^ permalink raw reply related
* [PATCH] fixup! audit: try harder to send to auditd upon netlink failure
From: Richard Guy Briggs @ 2015-09-18 7:52 UTC (permalink / raw)
To: linux-audit, linux-kernel
Cc: Richard Guy Briggs, sgrubb, pmoore, eparis, v.rathor, ctcard
A bug was introduced by "audit: try harder to send to auditd upon
netlink failure", caused by incomplete code and a function that expects
a string and does not accept a format plus arguments. Create a
temporary string variable to assemble the output text. It could be
merged as a fixup if it is not yet upstream.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
kernel/audit.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 18cdfe2..60913e6 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -420,7 +420,10 @@ restart:
if (audit_pid) {
if (err == -ECONNREFUSED || err == -EPERM
|| ++attempts >= AUDITD_RETRIES) {
- audit_log_lost("audit_pid=%d reset");
+ char s[32];
+
+ sprintf(s, "audit_pid=%d reset", audit_pid);
+ audit_log_lost(s);
audit_pid = 0;
audit_sock = NULL;
} else {
--
1.7.1
^ permalink raw reply related
* Re: auditd on nonexistent files
From: Steve Grubb @ 2015-09-18 0:22 UTC (permalink / raw)
To: Florian Crouzat; +Cc: linux-audit
In-Reply-To: <55F920CA.8020703@floriancrouzat.net>
On Wed, 16 Sep 2015 09:56:58 +0200
Florian Crouzat <tech@floriancrouzat.net> wrote:
> I asked the same question in the "Watching over non-existent folder to
> maintain a generic audit.rules file" thread but got different hints.
> I've been directed to augenrules which could help but this doesn't
> really match or facilitate my needs to replace my current FIM tool by
> auditd which requires me to write a generic configuration with all
> possibles folders (including applicative ones) and deploy accross all
> hosts without knowing which host runs which app and/or contains which
> folders.
That is not the intended way to use augenrules. The intention is to have
a base set of rules that apply to everything. Then drop in rules that
apply to that type of system. IOW, you would not put apache rules
on your DNS system because that doesn't make sense.
-Steve
^ 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-17 22:40 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: v.rathor, linux-audit, linux-kernel
In-Reply-To: <20150917113539.GA6873@madcap2.tricolour.ca>
On Thu, Sep 17, 2015 at 7:35 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 15/09/16, Paul Moore wrote:
>> Otherwise, I think adding a result/success field to the
>> AUDIT_CONFIG_CHANGE record makes sense as long as it doesn't break
>> Steve's parsing code (I don't think it will, although it may simply
>> ignore it, which is okay).
>
> It is already there, but never used for anything but success. I'm
> proposing to add code to actually report the failures too.
So it is, even better as there shouldn't be a userspace problem.
--
paul moore
www.paul-moore.com
^ 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-17 11:35 UTC (permalink / raw)
To: Paul Moore; +Cc: v.rathor, linux-kernel, linux-audit
In-Reply-To: <CAHC9VhQ=MqQzBE7qKeX6_qpMUWAmKaUUKKGthMuv8U7bszGU6Q@mail.gmail.com>
On 15/09/16, Paul Moore wrote:
> On Wed, Sep 16, 2015 at 6:24 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 15/09/14, Paul Moore wrote:
> >> On Sunday, September 13, 2015 12:08:19 PM Richard Guy Briggs wrote:
> >> > On 15/09/11, Paul Moore wrote:
> >> > > 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.
> >> >
> >> > This is actually a good idea.
> >>
> >> This would go well with your last patch to try harder on netlink send
> >> failures.
> >
> > Re-looking at the AUDIT_STATUS_PID case, I'm noticing we only
> > audit_log_config_change() on success. At the moment, auditd userspace
> > doesn't know about this new AUDIT_PING netlink message type I'm adding
> > for testing the health of the existing audit, so it will just be dropped
> > by existing auditd. I think it makes sense to add
> > audit_log_config_change() on both the orphaning and starving cases
> > indicating the result=0 so that there is a record. Arguably the
> > orphaning case can never happen again since the starving fix will
> > prevent a newer auditd from running.
>
> Just so I'm clear, the "starving" case is when a new auditd tries to
> evict a perfectly good auditd?
Not evict so much as trample. It just stomps on the existing audit_pid
reference and the old one isn't aware (unless it sends a status request
and checks the PID value) that it has been supplanted.
> Otherwise, I think adding a result/success field to the
> AUDIT_CONFIG_CHANGE record makes sense as long as it doesn't break
> Steve's parsing code (I don't think it will, although it may simply
> ignore it, which is okay).
It is already there, but never used for anything but success. I'm
proposing to add code to actually report the failures too.
> 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: [PATCH V1] audit: add warning that an old auditd may be starved out by a new auditd
From: Paul Moore @ 2015-09-16 21:45 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: v.rathor, linux-kernel, linux-audit
In-Reply-To: <20150916102435.GC8140@madcap2.tricolour.ca>
On Wed, Sep 16, 2015 at 6:24 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 15/09/14, Paul Moore wrote:
>> On Sunday, September 13, 2015 12:08:19 PM Richard Guy Briggs wrote:
>> > On 15/09/11, Paul Moore wrote:
>> > > 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.
>> >
>> > This is actually a good idea.
>>
>> This would go well with your last patch to try harder on netlink send
>> failures.
>
> Re-looking at the AUDIT_STATUS_PID case, I'm noticing we only
> audit_log_config_change() on success. At the moment, auditd userspace
> doesn't know about this new AUDIT_PING netlink message type I'm adding
> for testing the health of the existing audit, so it will just be dropped
> by existing auditd. I think it makes sense to add
> audit_log_config_change() on both the orphaning and starving cases
> indicating the result=0 so that there is a record. Arguably the
> orphaning case can never happen again since the starving fix will
> prevent a newer auditd from running.
Just so I'm clear, the "starving" case is when a new auditd tries to
evict a perfectly good auditd?
Otherwise, I think adding a result/success field to the
AUDIT_CONFIG_CHANGE record makes sense as long as it doesn't break
Steve's parsing code (I don't think it will, although it may simply
ignore it, which is okay).
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: Early processes (daemons) do not report audit events
From: Kangkook Jee @ 2015-09-16 13:08 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20150913155826.GR8140@madcap2.tricolour.ca>
[-- Attachment #1.1: Type: text/plain, Size: 7172 bytes --]
Dear Richard,
Thanks a lot for your help. I agree that the inconsistency seems a bit strange but
I also doubt that different distributions make different changes to kernel/audit.c. This
may be just a timing issue with regard to startup orderings.
I’d like to append Burn’s message that solved my issue for future reference.
>>>
>>> Kangkook,
>>>
>>> Perhaps you can re-test, but modify the kernel boot parameters to
>>> include audit=1 as an additional argument.
>>>
>>> Reading the auditd(8) manual, one sees
>>>
>>> A boot param of audit=1 should be added to ensure that all
>>> processes that run before the audit daemon starts is marked as
>>> auditable by the kernel. Not doing that will make a few
>>> processes impossible to properly audit.
Thanks again for your help!
Regards, Kangkook
> On Sep 13, 2015, at 11:58 AM, Richard Guy Briggs <rgb@redhat.com <mailto:rgb@redhat.com>> wrote:
>
> On 15/09/11, Kangkook Jee wrote:
>> Hi Richard,
>
> Hi Kangkook,
>
>> 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 <mailto: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.
>
> On all systems? This is expected behaviour. Sorry I was not more
> explicit in asking you to test that. I guess it was implied by asking
> what the settings for the kernel command line were.
>
> Now the surprising bit is that CentOS does not demonstrate the problem
> without audit=1 in the command line, which leads me to wonder if they
> have set "u32 audit_enabled = 1;" around line 83 of
> kernel/audit.c in their kernel source. It would surprise me if they
> did, but it would not be completely unreasonable.
>
>> Regards, Kangkook
>>
>>> On Sep 11, 2015, at 12:24 PM, Richard Guy Briggs <rgb@redhat.com <mailto: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 <mailto: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 <mailto: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
>>>>>
>>>>> - RGB
>>>
>>> - RGB
>
> - 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: 25300 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-16 10:24 UTC (permalink / raw)
To: Paul Moore; +Cc: v.rathor, linux-kernel, linux-audit
In-Reply-To: <19236209.prUueVMe32@sifl>
On 15/09/14, Paul Moore wrote:
> On Sunday, September 13, 2015 12:08:19 PM Richard Guy Briggs wrote:
> > On 15/09/11, Paul Moore wrote:
> > > 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.
> >
> > This is actually a good idea.
>
> This would go well with your last patch to try harder on netlink send
> failures.
Re-looking at the AUDIT_STATUS_PID case, I'm noticing we only
audit_log_config_change() on success. At the moment, auditd userspace
doesn't know about this new AUDIT_PING netlink message type I'm adding
for testing the health of the existing audit, so it will just be dropped
by existing auditd. I think it makes sense to add
audit_log_config_change() on both the orphaning and starving cases
indicating the result=0 so that there is a record. Arguably the
orphaning case can never happen again since the starving fix will
prevent a newer auditd from running.
> On a related note, with the merge window closed I just rotated the
> audit tree so that patch is now in linux-audit#next.
Thanks.
> 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: auditd on nonexistent files
From: Florian Crouzat @ 2015-09-16 7:56 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <20150915100734.GY8140@madcap2.tricolour.ca>
On 09/15/2015 12:07 PM, Richard Guy Briggs wrote:
> On 15/09/15, Steve Grubb wrote:
>> On Mon, 14 Sep 2015 16:01:17 +0000
>> Davíð Steinn Geirsson <dsg@sensa.is> wrote:
>>
>>> Hi all,
>>>
>>> What is the best practice for using auditd for file integrity
>>> monitoring?
>>>
>>> From the documentation, I have this, which works fine:
>>> -a always,exit -F dir=/bin -F perm=wa
>>>
>>> However, it seems that if I have a rule on a nonexistent directory,
>>> auditd will fail to add the rule (I assume because it's adding a watch
>>> on an inode or something like that?), but it will also just stop
>>> reading audit.rules and not add any subsequent rules.
>>>
>>> This is bad in an environment where we have to have FIM for critical
>>> application files, but where another team may be maintaining some of
>>> the apps and therefore might remove some watched directories,
>>> especially as their mishaps may impact auditing for other parts of
>>> the system.
>>>
>>> Can something be done to get better behaviour here?
>>>
>>> I see two ways it could be better
>>> 1) (the ideal case) auditd will add rules even for nonexistent
>>> directories, and when they are created will add a watch for them. If a
>>> directory is removed and another created with the same name, auditd
>>> will add a watch on the new directory.
>>
>> Which kernel are you using? I want to think this was fixed in kernels
>> around 2.6.36 or later. This original problem was that the audit
>> watches are based on inotify which needs an inode. If there's no inode,
>> you can't place the watch.
>
> A watch can be added for a file that does not exist while the containing
> directory does, but a directory that does not exist (when the containing
> directory does not exist) does not work.
>
>>> 2) auditd still cannot add watches to nonexistent directories, but a
>>> failed rule add from audit.rules will become a warning rather than an
>>> error so subsequent watches still get added.
>>
>> Check into adding -i or -c near the top of your rules.
>>
>> -Steve
>>
>>> I suspect 1) is not possible, but can I get auditd to behave like in
>>> 2)?
>
> 1) is not currently implemented, but is worth discussing.
>
>>> Davíð
I asked the same question in the "Watching over non-existent folder to
maintain a generic audit.rules file" thread but got different hints.
I've been directed to augenrules which could help but this doesn't
really match or facilitate my needs to replace my current FIM tool by
auditd which requires me to write a generic configuration with all
possibles folders (including applicative ones) and deploy accross all
hosts without knowing which host runs which app and/or contains which
folders.
I guess I'll stick by this thread now.
Have you tried the -i or -c hint ?
Florian
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: auditd on nonexistent files
From: Richard Guy Briggs @ 2015-09-15 10:07 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <20150915101503.0dd9e4d4@ivy-bridge>
On 15/09/15, Steve Grubb wrote:
> On Mon, 14 Sep 2015 16:01:17 +0000
> Davíð Steinn Geirsson <dsg@sensa.is> wrote:
>
> > Hi all,
> >
> > What is the best practice for using auditd for file integrity
> > monitoring?
> >
> > From the documentation, I have this, which works fine:
> > -a always,exit -F dir=/bin -F perm=wa
> >
> > However, it seems that if I have a rule on a nonexistent directory,
> > auditd will fail to add the rule (I assume because it's adding a watch
> > on an inode or something like that?), but it will also just stop
> > reading audit.rules and not add any subsequent rules.
> >
> > This is bad in an environment where we have to have FIM for critical
> > application files, but where another team may be maintaining some of
> > the apps and therefore might remove some watched directories,
> > especially as their mishaps may impact auditing for other parts of
> > the system.
> >
> > Can something be done to get better behaviour here?
> >
> > I see two ways it could be better
> > 1) (the ideal case) auditd will add rules even for nonexistent
> > directories, and when they are created will add a watch for them. If a
> > directory is removed and another created with the same name, auditd
> > will add a watch on the new directory.
>
> Which kernel are you using? I want to think this was fixed in kernels
> around 2.6.36 or later. This original problem was that the audit
> watches are based on inotify which needs an inode. If there's no inode,
> you can't place the watch.
A watch can be added for a file that does not exist while the containing
directory does, but a directory that does not exist (when the containing
directory does not exist) does not work.
> > 2) auditd still cannot add watches to nonexistent directories, but a
> > failed rule add from audit.rules will become a warning rather than an
> > error so subsequent watches still get added.
>
> Check into adding -i or -c near the top of your rules.
>
> -Steve
>
> > I suspect 1) is not possible, but can I get auditd to behave like in
> > 2)?
1) is not currently implemented, but is worth discussing.
> > Davíð
- 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: auditd on nonexistent files
From: Davíð Steinn Geirsson @ 2015-09-15 9:25 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <20150915101503.0dd9e4d4@ivy-bridge>
[-- Attachment #1.1: Type: text/plain, Size: 2178 bytes --]
Hi,
On 09/15/2015 09:15 AM, Steve Grubb wrote:
> On Mon, 14 Sep 2015 16:01:17 +0000
> Davíð Steinn Geirsson <dsg@sensa.is> wrote:
>
>> Hi all,
>>
>> What is the best practice for using auditd for file integrity
>> monitoring?
>>
>> From the documentation, I have this, which works fine:
>> -a always,exit -F dir=/bin -F perm=wa
>>
>> However, it seems that if I have a rule on a nonexistent directory,
>> auditd will fail to add the rule (I assume because it's adding a watch
>> on an inode or something like that?), but it will also just stop
>> reading audit.rules and not add any subsequent rules.
>>
>> This is bad in an environment where we have to have FIM for critical
>> application files, but where another team may be maintaining some of
>> the apps and therefore might remove some watched directories,
>> especially as their mishaps may impact auditing for other parts of
>> the system.
>>
>>
>> Can something be done to get better behaviour here?
>>
>> I see two ways it could be better
>> 1) (the ideal case) auditd will add rules even for nonexistent
>> directories, and when they are created will add a watch for them. If a
>> directory is removed and another created with the same name, auditd
>> will add a watch on the new directory.
>
> Which kernel are you using? I want to think this was fixed in kernels
> around 2.6.36 or later. This original problem was that the audit
> watches are based on inotify which needs an inode. If there's no inode,
> you can't place the watch.
The machines I'm working with are RHEL6 with 2.6.32, but I just tried
with a machine with a 3.18 kernel and got the same behaviour.
>
>
>> 2) auditd still cannot add watches to nonexistent directories, but a
>> failed rule add from audit.rules will become a warning rather than an
>> error so subsequent watches still get added.
>
> Check into adding -i or -c near the top of your rules.
Thanks, that helps for a workaround. Not sure how I missed that in the
manpage.
>
> -Steve
>
>
>> I suspect 1) is not possible, but can I get auditd to behave like in
>> 2)?
>>
>> Best regards,
>> Davíð
>>
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: auditd on nonexistent files
From: Steve Grubb @ 2015-09-15 9:15 UTC (permalink / raw)
To: Davíð Steinn Geirsson; +Cc: linux-audit
In-Reply-To: <55F6EF4D.7050203@sensa.is>
On Mon, 14 Sep 2015 16:01:17 +0000
Davíð Steinn Geirsson <dsg@sensa.is> wrote:
> Hi all,
>
> What is the best practice for using auditd for file integrity
> monitoring?
>
> From the documentation, I have this, which works fine:
> -a always,exit -F dir=/bin -F perm=wa
>
> However, it seems that if I have a rule on a nonexistent directory,
> auditd will fail to add the rule (I assume because it's adding a watch
> on an inode or something like that?), but it will also just stop
> reading audit.rules and not add any subsequent rules.
>
> This is bad in an environment where we have to have FIM for critical
> application files, but where another team may be maintaining some of
> the apps and therefore might remove some watched directories,
> especially as their mishaps may impact auditing for other parts of
> the system.
>
>
> Can something be done to get better behaviour here?
>
> I see two ways it could be better
> 1) (the ideal case) auditd will add rules even for nonexistent
> directories, and when they are created will add a watch for them. If a
> directory is removed and another created with the same name, auditd
> will add a watch on the new directory.
Which kernel are you using? I want to think this was fixed in kernels
around 2.6.36 or later. This original problem was that the audit
watches are based on inotify which needs an inode. If there's no inode,
you can't place the watch.
> 2) auditd still cannot add watches to nonexistent directories, but a
> failed rule add from audit.rules will become a warning rather than an
> error so subsequent watches still get added.
Check into adding -i or -c near the top of your rules.
-Steve
> I suspect 1) is not possible, but can I get auditd to behave like in
> 2)?
>
> Best regards,
> Davíð
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ 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-14 19:37 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: v.rathor, linux-kernel, linux-audit
In-Reply-To: <20150913160819.GT8140@madcap2.tricolour.ca>
On Sunday, September 13, 2015 12:08:19 PM Richard Guy Briggs wrote:
> On 15/09/11, Paul Moore wrote:
> > 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.
>
> This is actually a good idea.
This would go well with your last patch to try harder on netlink send
failures. On a related note, with the merge window closed I just rotated the
audit tree so that patch is now in linux-audit#next.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* auditd on nonexistent files
From: Davíð Steinn Geirsson @ 2015-09-14 16:01 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 1364 bytes --]
Hi all,
What is the best practice for using auditd for file integrity monitoring?
From the documentation, I have this, which works fine:
-a always,exit -F dir=/bin -F perm=wa
However, it seems that if I have a rule on a nonexistent directory,
auditd will fail to add the rule (I assume because it's adding a watch
on an inode or something like that?), but it will also just stop reading
audit.rules and not add any subsequent rules.
This is bad in an environment where we have to have FIM for critical
application files, but where another team may be maintaining some of the
apps and therefore might remove some watched directories, especially as
their mishaps may impact auditing for other parts of the system.
Can something be done to get better behaviour here?
I see two ways it could be better
1) (the ideal case) auditd will add rules even for nonexistent
directories, and when they are created will add a watch for them. If a
directory is removed and another created with the same name, auditd will
add a watch on the new directory.
2) auditd still cannot add watches to nonexistent directories, but a
failed rule add from audit.rules will become a warning rather than an
error so subsequent watches still get added.
I suspect 1) is not possible, but can I get auditd to behave like in 2)?
Best regards,
Davíð
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 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-13 16:08 UTC (permalink / raw)
To: Paul Moore; +Cc: Paul Moore, v.rathor, linux-kernel, linux-audit
In-Reply-To: <CAHC9VhQd9pT7uQnL8jGQawmEjQM8YvqkXaqKxFy0KuPWnMOGQA@mail.gmail.com>
On 15/09/11, Paul Moore wrote:
> 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.
Agreed.
> >> 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.
Agreed.
> > 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?
Then it won't notice until something does get queued. That would be the
purpose of sending a ping.
> 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.
This is actually a good idea.
> > 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-13 15:58 UTC (permalink / raw)
To: Kangkook Jee; +Cc: linux-audit
In-Reply-To: <43B84A86-63BA-4573-9F12-5510E5E404DD@gmail.com>
On 15/09/11, Kangkook Jee wrote:
> Hi Richard,
Hi Kangkook,
> 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.
On all systems? This is expected behaviour. Sorry I was not more
explicit in asking you to test that. I guess it was implied by asking
what the settings for the kernel command line were.
Now the surprising bit is that CentOS does not demonstrate the problem
without audit=1 in the command line, which leads me to wonder if they
have set "u32 audit_enabled = 1;" around line 83 of
kernel/audit.c in their kernel source. It would surprise me if they
did, but it would not be completely unreasonable.
> 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
> >>>
> >>> - RGB
> >
> > - RGB
- 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 20:17 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
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 --]
^ 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-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
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