* [PATCH 1/1] audit: CONFIG_CHANGE don't log internal bookkeeping as an event
@ 2020-01-05 15:22 Steve Grubb
2020-01-07 1:47 ` Paul Moore
0 siblings, 1 reply; 6+ messages in thread
From: Steve Grubb @ 2020-01-05 15:22 UTC (permalink / raw)
To: linux-audit
Common Criteria calls out for any action that modifies the audit trail to
be recorded. That usually is interpreted to mean insertion or removal of
rules. It is not required to log modification of the inode information
since the watch is still in effect. Additionally, if the rule is a never
rule and the underlying file is one they do not want events for, they
get an event for this bookkeeping update against their wishes.
Since no device/inode info is logged at insertion and no device/inode
information is logged on update, there is nothing meaningful being
communicated to the admin by the CONFIG_CHANGE updated_rules event. One
can assume that the rule was not "modified" because it is still watching
the intended target. If the device or inode cannot be resolved, then
audit_panic is called which is sufficient.
I think the correct resolution is to drop logging config_update events
since the watch is still in effect but just on another unknown inode.
Signed-off-by: Steve Grubb <sgrubb@redhat.com>
---
kernel/audit_watch.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 4508d5e0cf69..8a8fd732ff6d 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -302,8 +302,6 @@ static void audit_update_watch(struct audit_parent *parent,
if (oentry->rule.exe)
audit_remove_mark(oentry->rule.exe);
- audit_watch_log_rule_change(r, owatch, "updated_rules");
-
call_rcu(&oentry->rcu, audit_free_rule_rcu);
}
--
2.24.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] audit: CONFIG_CHANGE don't log internal bookkeeping as an event
2020-01-05 15:22 [PATCH 1/1] audit: CONFIG_CHANGE don't log internal bookkeeping as an event Steve Grubb
@ 2020-01-07 1:47 ` Paul Moore
2020-01-07 22:52 ` Steve Grubb
0 siblings, 1 reply; 6+ messages in thread
From: Paul Moore @ 2020-01-07 1:47 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
On Sun, Jan 5, 2020 at 10:22 AM Steve Grubb <sgrubb@redhat.com> wrote:
> Common Criteria calls out for any action that modifies the audit trail to
> be recorded. That usually is interpreted to mean insertion or removal of
> rules. It is not required to log modification of the inode information
> since the watch is still in effect. Additionally, if the rule is a never
> rule and the underlying file is one they do not want events for, they
> get an event for this bookkeeping update against their wishes.
>
> Since no device/inode info is logged at insertion and no device/inode
> information is logged on update, there is nothing meaningful being
> communicated to the admin by the CONFIG_CHANGE updated_rules event. One
> can assume that the rule was not "modified" because it is still watching
> the intended target. If the device or inode cannot be resolved, then
> audit_panic is called which is sufficient.
>
> I think the correct resolution is to drop logging config_update events
> since the watch is still in effect but just on another unknown inode.
Either this patch is the correct resolution or it isn't, the
description should state that clearly. If you are unsure we can
discuss it, but it sounds like you are certain that this record isn't
needed here, yes?
> Signed-off-by: Steve Grubb <sgrubb@redhat.com>
> ---
> kernel/audit_watch.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
> index 4508d5e0cf69..8a8fd732ff6d 100644
> --- a/kernel/audit_watch.c
> +++ b/kernel/audit_watch.c
> @@ -302,8 +302,6 @@ static void audit_update_watch(struct audit_parent *parent,
> if (oentry->rule.exe)
> audit_remove_mark(oentry->rule.exe);
>
> - audit_watch_log_rule_change(r, owatch, "updated_rules");
> -
> call_rcu(&oentry->rcu, audit_free_rule_rcu);
> }
>
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] audit: CONFIG_CHANGE don't log internal bookkeeping as an event
2020-01-07 1:47 ` Paul Moore
@ 2020-01-07 22:52 ` Steve Grubb
2020-01-07 23:29 ` Paul Moore
0 siblings, 1 reply; 6+ messages in thread
From: Steve Grubb @ 2020-01-07 22:52 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
On Monday, January 6, 2020 8:47:33 PM EST Paul Moore wrote:
> On Sun, Jan 5, 2020 at 10:22 AM Steve Grubb <sgrubb@redhat.com> wrote:
> > Common Criteria calls out for any action that modifies the audit trail to
> > be recorded. That usually is interpreted to mean insertion or removal of
> > rules. It is not required to log modification of the inode information
> > since the watch is still in effect. Additionally, if the rule is a never
> > rule and the underlying file is one they do not want events for, they
> > get an event for this bookkeeping update against their wishes.
> >
> > Since no device/inode info is logged at insertion and no device/inode
> > information is logged on update, there is nothing meaningful being
> > communicated to the admin by the CONFIG_CHANGE updated_rules event. One
> > can assume that the rule was not "modified" because it is still watching
> > the intended target. If the device or inode cannot be resolved, then
> > audit_panic is called which is sufficient.
> >
> > I think the correct resolution is to drop logging config_update events
> > since the watch is still in effect but just on another unknown inode.
>
> Either this patch is the correct resolution or it isn't, the
> description should state that clearly. If you are unsure we can
> discuss it, but it sounds like you are certain that this record isn't
> needed here, yes?
It's not needed based on the rationale above and it's irritating some people
because of that.
-Steve
> > Signed-off-by: Steve Grubb <sgrubb@redhat.com>
> > ---
> >
> > kernel/audit_watch.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
> > index 4508d5e0cf69..8a8fd732ff6d 100644
> > --- a/kernel/audit_watch.c
> > +++ b/kernel/audit_watch.c
> > @@ -302,8 +302,6 @@ static void audit_update_watch(struct audit_parent
> > *parent,>
> > if (oentry->rule.exe)
> >
> > audit_remove_mark(oentry->rule.exe);
> >
> > - audit_watch_log_rule_change(r, owatch,
> > "updated_rules"); -
> >
> > call_rcu(&oentry->rcu, audit_free_rule_rcu);
> >
> > }
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] audit: CONFIG_CHANGE don't log internal bookkeeping as an event
2020-01-07 22:52 ` Steve Grubb
@ 2020-01-07 23:29 ` Paul Moore
0 siblings, 0 replies; 6+ messages in thread
From: Paul Moore @ 2020-01-07 23:29 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
On Tue, Jan 7, 2020 at 5:52 PM Steve Grubb <sgrubb@redhat.com> wrote:
> On Monday, January 6, 2020 8:47:33 PM EST Paul Moore wrote:
> > On Sun, Jan 5, 2020 at 10:22 AM Steve Grubb <sgrubb@redhat.com> wrote:
> > > Common Criteria calls out for any action that modifies the audit trail to
> > > be recorded. That usually is interpreted to mean insertion or removal of
> > > rules. It is not required to log modification of the inode information
> > > since the watch is still in effect. Additionally, if the rule is a never
> > > rule and the underlying file is one they do not want events for, they
> > > get an event for this bookkeeping update against their wishes.
> > >
> > > Since no device/inode info is logged at insertion and no device/inode
> > > information is logged on update, there is nothing meaningful being
> > > communicated to the admin by the CONFIG_CHANGE updated_rules event. One
> > > can assume that the rule was not "modified" because it is still watching
> > > the intended target. If the device or inode cannot be resolved, then
> > > audit_panic is called which is sufficient.
> > >
> > > I think the correct resolution is to drop logging config_update events
> > > since the watch is still in effect but just on another unknown inode.
> >
> > Either this patch is the correct resolution or it isn't, the
> > description should state that clearly. If you are unsure we can
> > discuss it, but it sounds like you are certain that this record isn't
> > needed here, yes?
>
> It's not needed based on the rationale above and it's irritating some people
> because of that.
I didn't need you to repeat your conclusion, I needed you to rewrite
your patch description to remove the ambiguity and resubmit :)
To be clear, the phrase "I think the correct resolution ..." is the
problem; patches should be certain that their solution is correct.
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] audit: CONFIG_CHANGE don't log internal bookkeeping as an event
2020-01-08 13:37 Steve Grubb
@ 2020-01-09 4:42 ` Paul Moore
0 siblings, 0 replies; 6+ messages in thread
From: Paul Moore @ 2020-01-09 4:42 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
On Wed, Jan 8, 2020 at 8:37 AM Steve Grubb <sgrubb@redhat.com> wrote:
>
> Common Criteria calls out for any action that modifies the audit trail to
> be recorded. That usually is interpreted to mean insertion or removal of
> rules. It is not required to log modification of the inode information
> since the watch is still in effect. Additionally, if the rule is a never
> rule and the underlying file is one they do not want events for, they
> get an event for this bookkeeping update against their wishes.
>
> Since no device/inode info is logged at insertion and no device/inode
> information is logged on update, there is nothing meaningful being
> communicated to the admin by the CONFIG_CHANGE updated_rules event. One
> can assume that the rule was not "modified" because it is still watching
> the intended target. If the device or inode cannot be resolved, then
> audit_panic is called which is sufficient.
>
> The correct resolution is to drop logging config_update events since
> the watch is still in effect but just on another unknown inode.
>
> Signed-off-by: Steve Grubb <sgrubb@redhat.com>
> ---
> kernel/audit_watch.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
> index 4508d5e0cf69..8a8fd732ff6d 100644
> --- a/kernel/audit_watch.c
> +++ b/kernel/audit_watch.c
> @@ -302,8 +302,6 @@ static void audit_update_watch(struct audit_parent
> *parent,
It looks like your mail client is mangling your patch such that it
can't be applied directly from the mail you sent (look at the line
above). Granted this patch is trivial and easily applied by hand but
I think it would be good for you Steve to get the experience in
sending kernel patches properly, please try it again.
If you are unfamiliar with how to do it, I would suggest looking at
Documentation/process/submitting-patches.rst and
Documentation/process/email-clients.rst in the kernel source tree.
> if (oentry->rule.exe)
> audit_remove_mark(oentry->rule.exe);
>
> - audit_watch_log_rule_change(r, owatch, "updated_rules");
> -
> call_rcu(&oentry->rcu, audit_free_rule_rcu);
> }
>
> --
> 2.24.1
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 1/1] audit: CONFIG_CHANGE don't log internal bookkeeping as an event
@ 2020-01-08 13:37 Steve Grubb
2020-01-09 4:42 ` Paul Moore
0 siblings, 1 reply; 6+ messages in thread
From: Steve Grubb @ 2020-01-08 13:37 UTC (permalink / raw)
To: linux-audit
Common Criteria calls out for any action that modifies the audit trail to
be recorded. That usually is interpreted to mean insertion or removal of
rules. It is not required to log modification of the inode information
since the watch is still in effect. Additionally, if the rule is a never
rule and the underlying file is one they do not want events for, they
get an event for this bookkeeping update against their wishes.
Since no device/inode info is logged at insertion and no device/inode
information is logged on update, there is nothing meaningful being
communicated to the admin by the CONFIG_CHANGE updated_rules event. One
can assume that the rule was not "modified" because it is still watching
the intended target. If the device or inode cannot be resolved, then
audit_panic is called which is sufficient.
The correct resolution is to drop logging config_update events since
the watch is still in effect but just on another unknown inode.
Signed-off-by: Steve Grubb <sgrubb@redhat.com>
---
kernel/audit_watch.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 4508d5e0cf69..8a8fd732ff6d 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -302,8 +302,6 @@ static void audit_update_watch(struct audit_parent
*parent,
if (oentry->rule.exe)
audit_remove_mark(oentry->rule.exe);
- audit_watch_log_rule_change(r, owatch, "updated_rules");
-
call_rcu(&oentry->rcu, audit_free_rule_rcu);
}
--
2.24.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-09 4:43 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-05 15:22 [PATCH 1/1] audit: CONFIG_CHANGE don't log internal bookkeeping as an event Steve Grubb
2020-01-07 1:47 ` Paul Moore
2020-01-07 22:52 ` Steve Grubb
2020-01-07 23:29 ` Paul Moore
2020-01-08 13:37 Steve Grubb
2020-01-09 4:42 ` Paul Moore
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.