* Re: [RFC][PATCH] audit: add feature audit_lost reset
From: Paul Moore @ 2016-12-07 0:17 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20161206051337.GG22655@madcap2.tricolour.ca>
On Tue, Dec 6, 2016 at 12:13 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2016-12-05 12:48, Paul Moore wrote:
>> On Mon, Dec 5, 2016 at 11:52 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> > On 2016-12-05 11:02, Paul Moore wrote:
>> >> On Mon, Dec 5, 2016 at 3:02 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> >> > Add a method to reset the audit_lost value.
>> >> >
>> >> > An AUDIT_GET message will get the current audit_lost value and reset the
>> >> > counter to zero iff (if and only if) the AUDIT_FEATURE_LOST_RESET
>> >> > feature is set.
>> >> >
>> >> > If the flag AUDIT_FEATURE_BITMAP_LOST_RESET is present in the audit
>> >> > feature bitmap, the feature is settable by setting the
>> >> > AUDIT_FEATURE_LOST_RESET flag in the audit feature list with an
>> >> > AUDIT_SET_FEATURE call. This setting is lockable.
>> >> >
>> >> > See: https://github.com/linux-audit/audit-kernel/issues/3
>> >> >
>> >> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
>> >> > ---
>> >> > Note: The AUDIT_FEATURE_BITMAP_LOST_RESET check may not be necessary if
>> >> > it is possible to read all the entries from audit_feature_names from
>> >> > userspace.
>> >> > ---
>> >> > include/uapi/linux/audit.h | 7 +++++--
>> >> > kernel/audit.c | 9 ++++++---
>> >> > 2 files changed, 11 insertions(+), 5 deletions(-)
>> >>
>> >> Instead of resetting the lost counter on an AUDIT_GET if the reset
>> >> feature is set, how about preserving the AUDIT_GET behavior, skipping
>> >> the AUDIT_FEATURE_* addition, and simply reset the lost value by
>> >> sending a AUDIT_SET message with AUDIT_STATUS_LOST (you obviously have
>> >> to add this to the uapi header).
>> >
>> > I realized as I was coding it up that we would potentially lose an
>> > accurate count if the read and reset were not atomic. This was the
>> > reason for using atomic_xchg().
>>
>> Well, okay, but that isn't what I was talking about ... ? The
>> audit_cmd_mutex is held for both AUDIT_GET and AUDIT_SET so we should
>> never process these requests at the same time.
>
> I guess I still don't follow what you are talking about... I hadn't
> thought of including both an AUDIT_GET and an AUDIT_SET in the same skb,
> but that would ensure that no other command reads or resets the lost
> value. However, the lost value could still be incrementing on another
> CPU between these two commands, losing an accurate lost count.
Okay, back up ... this whole mess about atomic_xchg() was always
unrelated to my original suggestion, let's focus on my original
comment ... don't reset the counter on a AUDIT_GET, reset it on a
AUDIT_SET with an AUDIT_STATUS_LOST, does that make sense?
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [userspace PATCH] Prevent free() of stack buffer with NOLOG format
From: Steve Grubb @ 2016-12-06 15:55 UTC (permalink / raw)
To: George McCollister; +Cc: linux-audit
In-Reply-To: <CAFSKS=OdaX5wAJN7j2i9vQq9kU6A=zsbz9V0R3K1sqfDz4=Faw@mail.gmail.com>
On Tuesday, December 6, 2016 7:57:33 AM EST George McCollister wrote:
> On Mon, Dec 5, 2016 at 6:30 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Monday, December 5, 2016 6:01:02 PM EST George McCollister wrote:
> >> When the NOLOG format is used replace_event_msg() doesn't change
> >> e->reply.message so the message located on the stack is left and later is
> >
> >> free()'d in cleanup_event() resulting in the following:
> > Hmm...thanks for reporting this. Which version of audit are you using?
>
> I'm using 2.6.6 but I reproduced the problem and made the change
> against the HEAD of the master branch (using this mirror
> https://github.com/linux-audit/audit-userspace).
OK. Got it. The patch isn't exactly the right fix. While it may hide the
problem, the intent is that people may want to use the enriched format and
send logs to a remote collector. By any chance do you know which buffer on the
stack is getting freed? I'm trying to reproduce this but I thought I'd ask if
you where it is since you have already looked into it.
Thanks,
-Steve
^ permalink raw reply
* Re: [userspace PATCH] Prevent free() of stack buffer with NOLOG format
From: George McCollister @ 2016-12-06 13:57 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <2296915.lVJQe7gzRf@x2>
On Mon, Dec 5, 2016 at 6:30 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Monday, December 5, 2016 6:01:02 PM EST George McCollister wrote:
>> When the NOLOG format is used replace_event_msg() doesn't change
>> e->reply.message so the message located on the stack is left and later is
>> free()'d in cleanup_event() resulting in the following:
>
> Hmm...thanks for reporting this. Which version of audit are you using?
I'm using 2.6.6 but I reproduced the problem and made the change
against the HEAD of the master branch (using this mirror
https://github.com/linux-audit/audit-userspace).
-George
^ permalink raw reply
* Re: [RFC][PATCH] audit: add feature audit_lost reset
From: Richard Guy Briggs @ 2016-12-06 5:13 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <CAHC9VhSFgXsZk1+_rqvWbBKHxKRv3vj641yJfua9vWUBs9YkTw@mail.gmail.com>
On 2016-12-05 12:48, Paul Moore wrote:
> On Mon, Dec 5, 2016 at 11:52 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2016-12-05 11:02, Paul Moore wrote:
> >> On Mon, Dec 5, 2016 at 3:02 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> >> > Add a method to reset the audit_lost value.
> >> >
> >> > An AUDIT_GET message will get the current audit_lost value and reset the
> >> > counter to zero iff (if and only if) the AUDIT_FEATURE_LOST_RESET
> >> > feature is set.
> >> >
> >> > If the flag AUDIT_FEATURE_BITMAP_LOST_RESET is present in the audit
> >> > feature bitmap, the feature is settable by setting the
> >> > AUDIT_FEATURE_LOST_RESET flag in the audit feature list with an
> >> > AUDIT_SET_FEATURE call. This setting is lockable.
> >> >
> >> > See: https://github.com/linux-audit/audit-kernel/issues/3
> >> >
> >> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> >> > ---
> >> > Note: The AUDIT_FEATURE_BITMAP_LOST_RESET check may not be necessary if
> >> > it is possible to read all the entries from audit_feature_names from
> >> > userspace.
> >> > ---
> >> > include/uapi/linux/audit.h | 7 +++++--
> >> > kernel/audit.c | 9 ++++++---
> >> > 2 files changed, 11 insertions(+), 5 deletions(-)
> >>
> >> Instead of resetting the lost counter on an AUDIT_GET if the reset
> >> feature is set, how about preserving the AUDIT_GET behavior, skipping
> >> the AUDIT_FEATURE_* addition, and simply reset the lost value by
> >> sending a AUDIT_SET message with AUDIT_STATUS_LOST (you obviously have
> >> to add this to the uapi header).
> >
> > I realized as I was coding it up that we would potentially lose an
> > accurate count if the read and reset were not atomic. This was the
> > reason for using atomic_xchg().
>
> Well, okay, but that isn't what I was talking about ... ? The
> audit_cmd_mutex is held for both AUDIT_GET and AUDIT_SET so we should
> never process these requests at the same time.
I guess I still don't follow what you are talking about... I hadn't
thought of including both an AUDIT_GET and an AUDIT_SET in the same skb,
but that would ensure that no other command reads or resets the lost
value. However, the lost value could still be incrementing on another
CPU between these two commands, losing an accurate lost count.
> paul moore
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [userspace PATCH] Prevent free() of stack buffer with NOLOG format
From: Steve Grubb @ 2016-12-06 0:30 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <20161206000102.18324-1-george.mccollister@gmail.com>
On Monday, December 5, 2016 6:01:02 PM EST George McCollister wrote:
> When the NOLOG format is used replace_event_msg() doesn't change
> e->reply.message so the message located on the stack is left and later is
> free()'d in cleanup_event() resulting in the following:
Hmm...thanks for reporting this. Which version of audit are you using?
Steve
> *** Error in `auditd': free(): invalid pointer: 0x800bef7c ***
> ======= Backtrace: =========
> /lib/libc.so.6(+0x676ba)[0xb752b6ba]
> /lib/libc.so.6(+0x6e227)[0xb7532227]
> /lib/libc.so.6(+0x6e9e6)[0xb75329e6]
> auditd(+0x73df)[0x800a43df]
> auditd(+0x4975)[0x800a1975]
> auditd(+0x4a9c)[0x800a1a9c]
> auditd(main+0x931)[0x800a0c21]
> /lib/libc.so.6(__libc_start_main+0xf6)[0xb74dc1a6]
> auditd(+0x44c4)[0x800a14c4]
> ======= Memory map: ========
> ...
>
> This patch changes the log format to RAW when NOLOG format is detected
> so that replace_event_msg() will replace e->reply.message with a message
> that can be free()'d by cleanup_event().
>
> Signed-off-by: George McCollister <george.mccollister@gmail.com>
> ---
> src/auditd-config.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/auditd-config.c b/src/auditd-config.c
> index 584f079..bc06b1c 100644
> --- a/src/auditd-config.c
> +++ b/src/auditd-config.c
> @@ -839,6 +839,7 @@ static int log_format_parser(struct nv_pair *nv, int
> line, if (strcasecmp(nv->value, log_formats[i].name) == 0) {
> config->log_format = log_formats[i].option;
> if (config->log_format == LF_NOLOG) {
> + config->log_format = LF_RAW;
> audit_msg(LOG_WARNING,
> "The NOLOG option to log_format is deprecated. Please use
the
> write_logs option."); if (config->write_logs != 0)
^ permalink raw reply
* [userspace PATCH] Prevent free() of stack buffer with NOLOG format
From: George McCollister @ 2016-12-06 0:01 UTC (permalink / raw)
To: linux-audit
When the NOLOG format is used replace_event_msg() doesn't change
e->reply.message so the message located on the stack is left and later is
free()'d in cleanup_event() resulting in the following:
*** Error in `auditd': free(): invalid pointer: 0x800bef7c ***
======= Backtrace: =========
/lib/libc.so.6(+0x676ba)[0xb752b6ba]
/lib/libc.so.6(+0x6e227)[0xb7532227]
/lib/libc.so.6(+0x6e9e6)[0xb75329e6]
auditd(+0x73df)[0x800a43df]
auditd(+0x4975)[0x800a1975]
auditd(+0x4a9c)[0x800a1a9c]
auditd(main+0x931)[0x800a0c21]
/lib/libc.so.6(__libc_start_main+0xf6)[0xb74dc1a6]
auditd(+0x44c4)[0x800a14c4]
======= Memory map: ========
...
This patch changes the log format to RAW when NOLOG format is detected
so that replace_event_msg() will replace e->reply.message with a message
that can be free()'d by cleanup_event().
Signed-off-by: George McCollister <george.mccollister@gmail.com>
---
src/auditd-config.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/auditd-config.c b/src/auditd-config.c
index 584f079..bc06b1c 100644
--- a/src/auditd-config.c
+++ b/src/auditd-config.c
@@ -839,6 +839,7 @@ static int log_format_parser(struct nv_pair *nv, int line,
if (strcasecmp(nv->value, log_formats[i].name) == 0) {
config->log_format = log_formats[i].option;
if (config->log_format == LF_NOLOG) {
+ config->log_format = LF_RAW;
audit_msg(LOG_WARNING,
"The NOLOG option to log_format is deprecated. Please use the write_logs option.");
if (config->write_logs != 0)
--
2.9.3
^ permalink raw reply related
* Re: Auditd misses accept syscalls from sshd
From: Steve Grubb @ 2016-12-05 22:44 UTC (permalink / raw)
To: Nathan Cooprider; +Cc: linux-audit
In-Reply-To: <CAMMwpcgcHEKTbQvHHZpWiMGDoEnmm9bOz26HVq7CJk+eXg3jJg@mail.gmail.com>
On Monday, December 5, 2016 4:42:14 PM EST Nathan Cooprider wrote:
> On Sat, Dec 3, 2016 at 12:47 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > > Support was not added until 2.5.
> > >
> > > Support for what?
> >
> > Audit by executable. In the example that I gave I showed the syntax for
> > how you would audit accept only for sshd. I presume that you are not
> > auditing accept across the whole system. What rule are you using to audit
> > accept?
>
> Here's what I have:
>
> vagrant@vagrant:~$ uname -a
> Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 19:22:30
> UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> vagrant@vagrant:~$ sudo auditctl -l
> No rules
> vagrant@vagrant:~$ sudo auditctl -a exit,always -F arch=b64 -S accept
> vagrant@vagrant:~$ sudo auditctl -l
> LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=accept
>
> For my case, I am auditing accept syscalls across the whole system. I want
> to look for when that syscall occurs in my log and alert on it.
OK. I was thinking that perhaps you had the rule qualified with -F auid>=500 -F
auid!=-1 to detect user originating events and the restart (because its
upstart) would put your auid into sshd's and then you were successful in
auditing. If the above rule is in fact what you are auditing with, and you
have auidit=1 on your grub kernel boot commandline, then I am out of guesses.
Sounds like a problem unique to your kernel since you have found kernels that
work fine.
-Steve
^ permalink raw reply
* Re: [RFC][PATCH] audit: add feature audit_lost reset
From: Paul Moore @ 2016-12-05 17:48 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20161205165211.GF22655@madcap2.tricolour.ca>
On Mon, Dec 5, 2016 at 11:52 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2016-12-05 11:02, Paul Moore wrote:
>> On Mon, Dec 5, 2016 at 3:02 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> > Add a method to reset the audit_lost value.
>> >
>> > An AUDIT_GET message will get the current audit_lost value and reset the
>> > counter to zero iff (if and only if) the AUDIT_FEATURE_LOST_RESET
>> > feature is set.
>> >
>> > If the flag AUDIT_FEATURE_BITMAP_LOST_RESET is present in the audit
>> > feature bitmap, the feature is settable by setting the
>> > AUDIT_FEATURE_LOST_RESET flag in the audit feature list with an
>> > AUDIT_SET_FEATURE call. This setting is lockable.
>> >
>> > See: https://github.com/linux-audit/audit-kernel/issues/3
>> >
>> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
>> > ---
>> > Note: The AUDIT_FEATURE_BITMAP_LOST_RESET check may not be necessary if
>> > it is possible to read all the entries from audit_feature_names from
>> > userspace.
>> > ---
>> > include/uapi/linux/audit.h | 7 +++++--
>> > kernel/audit.c | 9 ++++++---
>> > 2 files changed, 11 insertions(+), 5 deletions(-)
>>
>> Instead of resetting the lost counter on an AUDIT_GET if the reset
>> feature is set, how about preserving the AUDIT_GET behavior, skipping
>> the AUDIT_FEATURE_* addition, and simply reset the lost value by
>> sending a AUDIT_SET message with AUDIT_STATUS_LOST (you obviously have
>> to add this to the uapi header).
>
> I realized as I was coding it up that we would potentially lose an
> accurate count if the read and reset were not atomic. This was the
> reason for using atomic_xchg().
Well, okay, but that isn't what I was talking about ... ? The
audit_cmd_mutex is held for both AUDIT_GET and AUDIT_SET so we should
never process these requests at the same time.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [RFC][PATCH] audit: add feature audit_lost reset
From: Richard Guy Briggs @ 2016-12-05 16:52 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <CAHC9VhQFSuzkOQAKbppdYEjq=csAdE7hYg4z1ZuKjz-JVTWP0A@mail.gmail.com>
On 2016-12-05 11:02, Paul Moore wrote:
> On Mon, Dec 5, 2016 at 3:02 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > Add a method to reset the audit_lost value.
> >
> > An AUDIT_GET message will get the current audit_lost value and reset the
> > counter to zero iff (if and only if) the AUDIT_FEATURE_LOST_RESET
> > feature is set.
> >
> > If the flag AUDIT_FEATURE_BITMAP_LOST_RESET is present in the audit
> > feature bitmap, the feature is settable by setting the
> > AUDIT_FEATURE_LOST_RESET flag in the audit feature list with an
> > AUDIT_SET_FEATURE call. This setting is lockable.
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/3
> >
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > Note: The AUDIT_FEATURE_BITMAP_LOST_RESET check may not be necessary if
> > it is possible to read all the entries from audit_feature_names from
> > userspace.
> > ---
> > include/uapi/linux/audit.h | 7 +++++--
> > kernel/audit.c | 9 ++++++---
> > 2 files changed, 11 insertions(+), 5 deletions(-)
>
> Instead of resetting the lost counter on an AUDIT_GET if the reset
> feature is set, how about preserving the AUDIT_GET behavior, skipping
> the AUDIT_FEATURE_* addition, and simply reset the lost value by
> sending a AUDIT_SET message with AUDIT_STATUS_LOST (you obviously have
> to add this to the uapi header).
I realized as I was coding it up that we would potentially lose an
accurate count if the read and reset were not atomic. This was the
reason for using atomic_xchg().
> I'm mixed on adding this to the feature bitmap, it shouldn't be
> strictly necessary as old kernels will simply ignore the
> AUDIT_SET/AUDIT_STATUS_LOST bit, but I can understand if userspace
> might want it ... I just hate to burn a bit in the bitmap for
> something that has no ill effect on behavior.
As pointed out, we may not need the bitmap addition if we can read the
array of audit_feature_names.
> > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > index 208df7b..5eb2dc2 100644
> > --- a/include/uapi/linux/audit.h
> > +++ b/include/uapi/linux/audit.h
> > @@ -330,10 +330,12 @@ enum {
> > #define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME 0x00000002
> > #define AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH 0x00000004
> > #define AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND 0x00000008
> > +#define AUDIT_FEATURE_BITMAP_LOST_RESET 0x00000010
> > #define AUDIT_FEATURE_BITMAP_ALL (AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT | \
> > AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME | \
> > AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH | \
> > - AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND)
> > + AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND | \
> > + AUDIT_FEATURE_BITMAP_LOST_RESET)
> >
> > /* deprecated: AUDIT_VERSION_* */
> > #define AUDIT_VERSION_LATEST AUDIT_FEATURE_BITMAP_ALL
> > @@ -440,7 +442,8 @@ struct audit_features {
> >
> > #define AUDIT_FEATURE_ONLY_UNSET_LOGINUID 0
> > #define AUDIT_FEATURE_LOGINUID_IMMUTABLE 1
> > -#define AUDIT_LAST_FEATURE AUDIT_FEATURE_LOGINUID_IMMUTABLE
> > +#define AUDIT_FEATURE_LOST_RESET 2
> > +#define AUDIT_LAST_FEATURE AUDIT_FEATURE_LOST_RESET
> >
> > #define audit_feature_valid(x) ((x) >= 0 && (x) <= AUDIT_LAST_FEATURE)
> > #define AUDIT_FEATURE_TO_MASK(x) (1 << ((x) & 31)) /* mask for __u32 */
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index f1ca116..6b52da6 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -122,7 +122,7 @@
> > 3) suppressed due to audit_rate_limit
> > 4) suppressed due to audit_backlog_limit
> > */
> > -static atomic_t audit_lost = ATOMIC_INIT(0);
> > +static atomic_t audit_lost = ATOMIC_INIT(0);
> >
> > /* The netlink socket. */
> > static struct sock *audit_sock;
> > @@ -150,9 +150,10 @@
> > .features = 0,
> > .lock = 0,};
> >
> > -static char *audit_feature_names[2] = {
> > +static char *audit_feature_names[3] = {
> > "only_unset_loginuid",
> > "loginuid_immutable",
> > + "lost_reset",
> > };
> >
> >
> > @@ -854,7 +855,9 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
> > s.pid = audit_pid;
> > s.rate_limit = audit_rate_limit;
> > s.backlog_limit = audit_backlog_limit;
> > - s.lost = atomic_read(&audit_lost);
> > + s.lost = is_audit_feature_set(AUDIT_FEATURE_LOST_RESET) ?
> > + atomic_xchg(&audit_lost, 0) :
> > + atomic_read(&audit_lost);
> > s.backlog = skb_queue_len(&audit_skb_queue);
> > s.feature_bitmap = AUDIT_FEATURE_BITMAP_ALL;
> > s.backlog_wait_time = audit_backlog_wait_time_master;
> > --
> > 1.7.1
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>
> --
> paul moore
> www.paul-moore.com
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: EOE events in auparse output
From: Nikolai Kondrashov @ 2016-12-05 16:49 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <8276321.D6A7ZRxJEI@x2>
On 12/05/2016 05:54 PM, Steve Grubb wrote:
> On Monday, December 5, 2016 5:34:12 PM EST Nikolai Kondrashov wrote:
>> However, since libauparse is supposed to provide the service of
>> communicating event boundaries to its users, does it make sense for it to
>> return the EOE record? Especially as a separate, empty event, which doesn't
>> add any information?
>
> I suppose it could be stripped from the event as its real purpose is locating
> the event boundary. Since I don't know if the event will be relayed on to
> another analytic processor I've just kept it there. For example, you could
> have a realtime plugin that passes its information to another process for
> correlation and escalation. In that case keeping the record makes sense.
Hmm, perhaps, but I think it's not a useful feature, and a rather confusing
one. I think there aren't many actual use cases between simply passing the raw
log, and passing what was parsed with auparse, in whatever shape, and had
event boundaries explicitly defined already. However, I'd leave this up to
you.
> But for xml/json it can be dropped because it has its own way of defining an
> event boundary.
Yes, I can implement dropping it.
Thanks!
Nick
^ permalink raw reply
* Re: Auditd misses accept syscalls from sshd
From: Nathan Cooprider @ 2016-12-05 16:42 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <7841465.GifJlmNWiC@x2>
[-- Attachment #1.1: Type: text/plain, Size: 8872 bytes --]
On Sat, Dec 3, 2016 at 12:47 PM Steve Grubb <sgrubb@redhat.com> wrote:
> On Saturday, December 3, 2016 2:11:04 AM EST Nathan Cooprider wrote:
> > Hi! It sounds like I'm missing something obvious!
> >
> > On Fri, Dec 2, 2016 at 5:13 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > Hello,
> > >
> > > Addressing a couple obvious things here...
> > >
> > > On Friday, December 2, 2016 9:55:17 PM EST Nathan Cooprider wrote:
> > > > On Fri, Dec 2, 2016 at 4:09 PM Steve Grubb <sgrubb@redhat.com>
> wrote:
> > > > > On Friday, December 2, 2016 8:43:46 PM EST Nathan Cooprider wrote:
> > > > > > Auditd seems to miss accept syscalls from ssh on Ubuntu 14.
> > > > >
> > > > > Its not auditd, the kernel does all the work. Auditd acts a lot
> like a
> > > > > specialized syslog. :-)
> > > > >
> > > > > > I tried versions 2.3.2 and 2.4.5 of the daemon
> > >
> > > Support was not added until 2.5.
> >
> > Support for what?
>
> Audit by executable. In the example that I gave I showed the syntax for how
> you would audit accept only for sshd. I presume that you are not auditing
> accept across the whole system. What rule are you using to audit accept?
>
Here's what I have:
vagrant@vagrant:~$ uname -a
Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 19:22:30
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
vagrant@vagrant:~$ sudo auditctl -l
No rules
vagrant@vagrant:~$ sudo auditctl -a exit,always -F arch=b64 -S accept
vagrant@vagrant:~$ sudo auditctl -l
LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=accept
For my case, I am auditing accept syscalls across the whole system. I want
to look for when that syscall occurs in my log and alert on it.
> > Auditing the accept syscall? What do you mean by "support?" Those are
> auditd
> > versions that I'm talking about. Is that what you mean? Sorry if I was
> not
> > clear. What did it do with accept syscalls before then? I do not see this
> > reflected in the changelog
>
> Let's take a look at how you are auditing it and maybe that will explain a
> few
> things. Also, does Ubuntu 14 use upstart or systemd? And perhaps for good
> measure include just 1 event when it does work.
>
Ubuntu 14 uses upstart. Specifically, my VM is using upstart 1.12.1.
I should note that I tried this on CentOS 6 this morning and it did not
have this issue.
Here's the output from audit for my test, with <> tags indicating when
something happened in another terminal:
vagrant@vagrant:~$ sudo auditd -f
Config file /etc/audit/auditd.conf opened for parsing
log_file_parser called with: /var/log/audit/audit.log
log_format_parser called with: RAW
log_group_parser called with: root
priority_boost_parser called with: 4
flush_parser called with: INCREMENTAL
freq_parser called with: 20
num_logs_parser called with: 5
qos_parser called with: lossy
dispatch_parser called with: /sbin/audispd
name_format_parser called with: NONE
max_log_size_parser called with: 6
max_log_size_action_parser called with: ROTATE
space_left_parser called with: 75
space_action_parser called with: SYSLOG
action_mail_acct_parser called with: root
admin_space_left_parser called with: 50
admin_space_left_action_parser called with: SUSPEND
disk_full_action_parser called with: SUSPEND
disk_error_action_parser called with: SUSPEND
tcp_listen_queue_parser called with: 5
Listener support is not enabled, ignoring value at line 26
tcp_max_per_addr_parser called with: 1
Listener support is not enabled, ignoring value at line 27
tcp_client_max_idle_parser called with: 0
Listener support is not enabled, ignoring value at line 29
enable_krb5_parser called with: no
krb5_principal_parser called with: auditd
Started dispatcher: /sbin/audispd pid: 20106
type=DAEMON_START msg=audit(1480954770.929:9566): auditd start, ver=2.3.2
format=raw kernel=4.4.0-51-generic auid=1000 pid=20104 subj=unconfined
res=success
config_manager init complete
Init complete, auditd 2.3.2 listening for events (startup state enable)
<An ssh log in before restarting ssh>
type=USER_LOGIN msg=audit(1480954826.056:416): pid=20108 uid=0
auid=4294967295 ses=4294967295 msg='op=login acct="vagrant"
exe="/usr/sbin/sshd" hostname=? addr=10.0.2.2 terminal=sshd res=failed'
type=USER_ACCT msg=audit(1480954826.064:417): pid=20108 uid=0
auid=4294967295 ses=4294967295 msg='op=PAM:accounting acct="vagrant"
exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh
res=success'
type=CRED_ACQ msg=audit(1480954826.068:418): pid=20108 uid=0
auid=4294967295 ses=4294967295 msg='op=PAM:setcred acct="vagrant"
exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh
res=success'
type=LOGIN msg=audit(1480954826.068:419): pid=20108 uid=0
old-auid=4294967295 auid=1000 old-ses=4294967295 ses=6 res=1
type=USER_START msg=audit(1480954826.404:420): pid=20108 uid=0 auid=1000
ses=6 msg='op=PAM:session_open acct="vagrant" exe="/usr/sbin/sshd"
hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh res=success'
type=CRED_ACQ msg=audit(1480954826.404:421): pid=20175 uid=0 auid=1000
ses=6 msg='op=PAM:setcred acct="vagrant" exe="/usr/sbin/sshd"
hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh res=success'
type=USER_LOGIN msg=audit(1480954826.404:422): pid=20108 uid=0 auid=1000
ses=6 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.0.2.2
addr=10.0.2.2 terminal=/dev/pts/1 res=success'
<Restarting ssh>
type=USER_START msg=audit(1480954850.688:423): pid=20190 uid=0 auid=1000
ses=6 msg='op=PAM:session_open acct="root" exe="/usr/bin/sudo" hostname=?
addr=? terminal=/dev/pts/1 res=success'
type=USER_END msg=audit(1480954850.720:424): pid=20190 uid=0 auid=1000
ses=6 msg='op=PAM:session_close acct="root" exe="/usr/bin/sudo" hostname=?
addr=? terminal=/dev/pts/1 res=success'
<After restarting ssh, so the accept event comes in now when I log in>
type=SYSCALL msg=audit(1480954895.508:425): arch=c000003e *syscall=43*
success=yes exit=5 a0=3 a1=7ffd736315c0 a2=7ffd736315ac a3=0 items=0 ppid=1
pid=20204 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
key=(null)
type=SOCKADDR msg=audit(1480954895.508:425):
saddr=0200CE760A0002020000000000000000
type=UNKNOWN[1327] msg=audit(1480954895.508:425):
proctitle=2F7573722F7362696E2F73736864002D44
type=USER_LOGIN msg=audit(1480954895.524:426): pid=20206 uid=0
auid=4294967295 ses=4294967295 msg='op=login acct="vagrant"
exe="/usr/sbin/sshd" hostname=? addr=10.0.2.2 terminal=sshd res=failed'
type=USER_ACCT msg=audit(1480954895.532:427): pid=20206 uid=0
auid=4294967295 ses=4294967295 msg='op=PAM:accounting acct="vagrant"
exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh
res=success'
type=CRED_ACQ msg=audit(1480954895.536:428): pid=20206 uid=0
auid=4294967295 ses=4294967295 msg='op=PAM:setcred acct="vagrant"
exe="/usr/sbin/sshd" hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh
res=success'
type=LOGIN msg=audit(1480954895.536:429): pid=20206 uid=0
old-auid=4294967295 auid=1000 old-ses=4294967295 ses=7 res=1
type=USER_START msg=audit(1480954895.772:430): pid=20206 uid=0 auid=1000
ses=7 msg='op=PAM:session_open acct="vagrant" exe="/usr/sbin/sshd"
hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh res=success'
type=CRED_ACQ msg=audit(1480954895.772:431): pid=20270 uid=0 auid=1000
ses=7 msg='op=PAM:setcred acct="vagrant" exe="/usr/sbin/sshd"
hostname=10.0.2.2 addr=10.0.2.2 terminal=ssh res=success'
type=USER_LOGIN msg=audit(1480954895.772:432): pid=20206 uid=0 auid=1000
ses=7 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.0.2.2
addr=10.0.2.2 terminal=/dev/pts/3 res=success'
-Steve
>
> > https://people.redhat.com/sgrubb/audit/ChangeLog
> >
> > > > > with kernel versions 3.13.0-96
> > >
> > > Definitely won't support it.
> >
> > Support what?
> >
> > > > > > and 4.4.0-47.
> > >
> > > The feature landed in 4.3, so 4.4 should have it. However, you need
> audit
> > > 2.5
> > > or later to use the kernel feature.
> >
> > What feature are you talking about? This sounds like it could be the
> issue,
> > but I am not sure to what you are actually referring.
> >
> > > > I just tried again and had the same problem:
> > > > vagrant@vagrant:~$ uname -a
> > > > Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24
> > > > 19:22:30
> > > > UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> > >
> > > Try pairing that with a newer auditd so that auditctl has the support
> to
> > > load
> > > the rule.
> >
> > I'll check this out. My initial attempts to compile more recent versions
> > than 2.4.5 on the newer kernel in Ubuntu 14 had issues, but those are
> > probably personal problems.
> >
> > > -Steve
> > >
> > > > That's a newer version than I have on my Ubuntu 16 VM, which does
> > > > demonstrate the problem. It's also strange that restarting ssh then
> > > > makes
> > > > the accept syscall events show up. Other sshd syscalls show up in
> auditd
> > > > before and after the ssh restart.
>
[-- Attachment #1.2: Type: text/html, Size: 12820 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH] audit: add feature audit_lost reset
From: Paul Moore @ 2016-12-05 16:02 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <4441ca24ceedf9aabe05e2bdaae213667ee59ef1.1480765170.git.rgb@redhat.com>
On Mon, Dec 5, 2016 at 3:02 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> Add a method to reset the audit_lost value.
>
> An AUDIT_GET message will get the current audit_lost value and reset the
> counter to zero iff (if and only if) the AUDIT_FEATURE_LOST_RESET
> feature is set.
>
> If the flag AUDIT_FEATURE_BITMAP_LOST_RESET is present in the audit
> feature bitmap, the feature is settable by setting the
> AUDIT_FEATURE_LOST_RESET flag in the audit feature list with an
> AUDIT_SET_FEATURE call. This setting is lockable.
>
> See: https://github.com/linux-audit/audit-kernel/issues/3
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> Note: The AUDIT_FEATURE_BITMAP_LOST_RESET check may not be necessary if
> it is possible to read all the entries from audit_feature_names from
> userspace.
> ---
> include/uapi/linux/audit.h | 7 +++++--
> kernel/audit.c | 9 ++++++---
> 2 files changed, 11 insertions(+), 5 deletions(-)
Instead of resetting the lost counter on an AUDIT_GET if the reset
feature is set, how about preserving the AUDIT_GET behavior, skipping
the AUDIT_FEATURE_* addition, and simply reset the lost value by
sending a AUDIT_SET message with AUDIT_STATUS_LOST (you obviously have
to add this to the uapi header).
I'm mixed on adding this to the feature bitmap, it shouldn't be
strictly necessary as old kernels will simply ignore the
AUDIT_SET/AUDIT_STATUS_LOST bit, but I can understand if userspace
might want it ... I just hate to burn a bit in the bitmap for
something that has no ill effect on behavior.
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index 208df7b..5eb2dc2 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -330,10 +330,12 @@ enum {
> #define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME 0x00000002
> #define AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH 0x00000004
> #define AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND 0x00000008
> +#define AUDIT_FEATURE_BITMAP_LOST_RESET 0x00000010
> #define AUDIT_FEATURE_BITMAP_ALL (AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT | \
> AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME | \
> AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH | \
> - AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND)
> + AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND | \
> + AUDIT_FEATURE_BITMAP_LOST_RESET)
>
> /* deprecated: AUDIT_VERSION_* */
> #define AUDIT_VERSION_LATEST AUDIT_FEATURE_BITMAP_ALL
> @@ -440,7 +442,8 @@ struct audit_features {
>
> #define AUDIT_FEATURE_ONLY_UNSET_LOGINUID 0
> #define AUDIT_FEATURE_LOGINUID_IMMUTABLE 1
> -#define AUDIT_LAST_FEATURE AUDIT_FEATURE_LOGINUID_IMMUTABLE
> +#define AUDIT_FEATURE_LOST_RESET 2
> +#define AUDIT_LAST_FEATURE AUDIT_FEATURE_LOST_RESET
>
> #define audit_feature_valid(x) ((x) >= 0 && (x) <= AUDIT_LAST_FEATURE)
> #define AUDIT_FEATURE_TO_MASK(x) (1 << ((x) & 31)) /* mask for __u32 */
> diff --git a/kernel/audit.c b/kernel/audit.c
> index f1ca116..6b52da6 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -122,7 +122,7 @@
> 3) suppressed due to audit_rate_limit
> 4) suppressed due to audit_backlog_limit
> */
> -static atomic_t audit_lost = ATOMIC_INIT(0);
> +static atomic_t audit_lost = ATOMIC_INIT(0);
>
> /* The netlink socket. */
> static struct sock *audit_sock;
> @@ -150,9 +150,10 @@
> .features = 0,
> .lock = 0,};
>
> -static char *audit_feature_names[2] = {
> +static char *audit_feature_names[3] = {
> "only_unset_loginuid",
> "loginuid_immutable",
> + "lost_reset",
> };
>
>
> @@ -854,7 +855,9 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
> s.pid = audit_pid;
> s.rate_limit = audit_rate_limit;
> s.backlog_limit = audit_backlog_limit;
> - s.lost = atomic_read(&audit_lost);
> + s.lost = is_audit_feature_set(AUDIT_FEATURE_LOST_RESET) ?
> + atomic_xchg(&audit_lost, 0) :
> + atomic_read(&audit_lost);
> s.backlog = skb_queue_len(&audit_skb_queue);
> s.feature_bitmap = AUDIT_FEATURE_BITMAP_ALL;
> s.backlog_wait_time = audit_backlog_wait_time_master;
> --
> 1.7.1
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: EOE events in auparse output
From: Steve Grubb @ 2016-12-05 15:54 UTC (permalink / raw)
To: Nikolai Kondrashov; +Cc: linux-audit
In-Reply-To: <029e3140-0633-ad77-b0d9-c4af223c10d7@redhat.com>
On Monday, December 5, 2016 5:34:12 PM EST Nikolai Kondrashov wrote:
> However, since libauparse is supposed to provide the service of
> communicating event boundaries to its users, does it make sense for it to
> return the EOE record? Especially as a separate, empty event, which doesn't
> add any information?
I suppose it could be stripped from the event as its real purpose is locating
the event boundary. Since I don't know if the event will be relayed on to
another analytic processor I've just kept it there. For example, you could
have a realtime plugin that passes its information to another process for
correlation and escalation. In that case keeping the record makes sense. But
for xml/json it can be dropped because it has its own way of defining an event
boundary.
-Steve
^ permalink raw reply
* Re: EOE events in auparse output
From: Nikolai Kondrashov @ 2016-12-05 15:34 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <1583364.QtL6vz97jr@x2>
Hi Steve,
Thank you for a quick answer, please see my answer below.
On 12/05/2016 05:27 PM, Steve Grubb wrote:
> On Monday, December 5, 2016 3:00:39 PM EST Nikolai Kondrashov wrote:
>> I was playing with auditd and aushape on Fedora 24 and found some strange
>> entries in my log. There was a separate *event* produced by auparse
>> containing a single EOE record. These events had the same serial number as
>> the directly preceding events, which were exclusively containing SYSCALL
>> records.
>>
>> Those EOE records didn't appear in the audit.log file.
>>
>> Is this a bug? Is this normal?
>
> The record is not created by auparse. The kernel sends this whenever there is
> a multipart event. This record is stripped before putting the event to disk to
> save disk space. We can get along with this because it can be deduced later
> and running reports from disk is not realtime. On the realtime interface it is
> passed along so that recognizing that an event is complete can occur
> immediately upon receipt. Realtime event processing kind of needs this
> guarantee.
I was able to find the original patch adding the EOE record output and
discussion around it, so I understand its purpose.
However, since libauparse is supposed to provide the service of communicating
event boundaries to its users, does it make sense for it to return the EOE
record? Especially as a separate, empty event, which doesn't add any
information?
Nick
^ permalink raw reply
* Re: EOE events in auparse output
From: Steve Grubb @ 2016-12-05 15:27 UTC (permalink / raw)
To: Nikolai Kondrashov; +Cc: linux-audit
In-Reply-To: <6ac1558f-fe8b-3e6a-decf-cdb31c180505@redhat.com>
On Monday, December 5, 2016 3:00:39 PM EST Nikolai Kondrashov wrote:
> I was playing with auditd and aushape on Fedora 24 and found some strange
> entries in my log. There was a separate *event* produced by auparse
> containing a single EOE record. These events had the same serial number as
> the directly preceding events, which were exclusively containing SYSCALL
> records.
>
> Those EOE records didn't appear in the audit.log file.
>
> Is this a bug? Is this normal?
The record is not created by auparse. The kernel sends this whenever there is
a multipart event. This record is stripped before putting the event to disk to
save disk space. We can get along with this because it can be deduced later
and running reports from disk is not realtime. On the realtime interface it is
passed along so that recognizing that an event is complete can occur
immediately upon receipt. Realtime event processing kind of needs this
guarantee.
-Steve
^ permalink raw reply
* EOE events in auparse output
From: Nikolai Kondrashov @ 2016-12-05 13:00 UTC (permalink / raw)
To: linux-audit, Steven Grubb
Hi Steve, everyone,
I was playing with auditd and aushape on Fedora 24 and found some strange
entries in my log. There was a separate *event* produced by auparse containing
a single EOE record. These events had the same serial number as the directly
preceding events, which were exclusively containing SYSCALL records.
Those EOE records didn't appear in the audit.log file.
Is this a bug? Is this normal?
Thank you.
Nick
^ permalink raw reply
* Re: [PATCH] audit: skip sessionid sentinel value when auto-incrementing
From: Richard Guy Briggs @ 2016-12-05 8:04 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <2e99896c655ae31ea481240692a720e9701b0a76.1478758980.git.rgb@redhat.com>
On 2016-12-05 02:55, Richard Guy Briggs wrote:
> The value (unsigned int)-1 is used as a sentinel to indicate the
> sessionID is unset. Skip this value when the session_id value wraps.
I'm very sorry, this was a brain fart. I sent/resent this patch by
accident, please ignore!
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/auditsc.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 5abf1dc..e414dfa 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2025,8 +2025,11 @@ int audit_set_loginuid(kuid_t loginuid)
> goto out;
>
> /* are we setting or clearing? */
> - if (uid_valid(loginuid))
> + if (uid_valid(loginuid)) {
> sessionid = (unsigned int)atomic_inc_return(&session_id);
> + if (unlikely(sessionid == (unsigned int)-1))
> + sessionid = (unsigned int)atomic_inc_return(&session_id);
> + }
>
> task->sessionid = sessionid;
> task->loginuid = loginuid;
> --
> 1.7.1
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* [RFC][PATCH] audit: add feature audit_lost reset
From: Richard Guy Briggs @ 2016-12-05 8:02 UTC (permalink / raw)
To: linux-audit; +Cc: Richard Guy Briggs
Add a method to reset the audit_lost value.
An AUDIT_GET message will get the current audit_lost value and reset the
counter to zero iff (if and only if) the AUDIT_FEATURE_LOST_RESET
feature is set.
If the flag AUDIT_FEATURE_BITMAP_LOST_RESET is present in the audit
feature bitmap, the feature is settable by setting the
AUDIT_FEATURE_LOST_RESET flag in the audit feature list with an
AUDIT_SET_FEATURE call. This setting is lockable.
See: https://github.com/linux-audit/audit-kernel/issues/3
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
Note: The AUDIT_FEATURE_BITMAP_LOST_RESET check may not be necessary if
it is possible to read all the entries from audit_feature_names from
userspace.
---
include/uapi/linux/audit.h | 7 +++++--
kernel/audit.c | 9 ++++++---
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 208df7b..5eb2dc2 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -330,10 +330,12 @@ enum {
#define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME 0x00000002
#define AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH 0x00000004
#define AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND 0x00000008
+#define AUDIT_FEATURE_BITMAP_LOST_RESET 0x00000010
#define AUDIT_FEATURE_BITMAP_ALL (AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT | \
AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME | \
AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH | \
- AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND)
+ AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND | \
+ AUDIT_FEATURE_BITMAP_LOST_RESET)
/* deprecated: AUDIT_VERSION_* */
#define AUDIT_VERSION_LATEST AUDIT_FEATURE_BITMAP_ALL
@@ -440,7 +442,8 @@ struct audit_features {
#define AUDIT_FEATURE_ONLY_UNSET_LOGINUID 0
#define AUDIT_FEATURE_LOGINUID_IMMUTABLE 1
-#define AUDIT_LAST_FEATURE AUDIT_FEATURE_LOGINUID_IMMUTABLE
+#define AUDIT_FEATURE_LOST_RESET 2
+#define AUDIT_LAST_FEATURE AUDIT_FEATURE_LOST_RESET
#define audit_feature_valid(x) ((x) >= 0 && (x) <= AUDIT_LAST_FEATURE)
#define AUDIT_FEATURE_TO_MASK(x) (1 << ((x) & 31)) /* mask for __u32 */
diff --git a/kernel/audit.c b/kernel/audit.c
index f1ca116..6b52da6 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -122,7 +122,7 @@
3) suppressed due to audit_rate_limit
4) suppressed due to audit_backlog_limit
*/
-static atomic_t audit_lost = ATOMIC_INIT(0);
+static atomic_t audit_lost = ATOMIC_INIT(0);
/* The netlink socket. */
static struct sock *audit_sock;
@@ -150,9 +150,10 @@
.features = 0,
.lock = 0,};
-static char *audit_feature_names[2] = {
+static char *audit_feature_names[3] = {
"only_unset_loginuid",
"loginuid_immutable",
+ "lost_reset",
};
@@ -854,7 +855,9 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
s.pid = audit_pid;
s.rate_limit = audit_rate_limit;
s.backlog_limit = audit_backlog_limit;
- s.lost = atomic_read(&audit_lost);
+ s.lost = is_audit_feature_set(AUDIT_FEATURE_LOST_RESET) ?
+ atomic_xchg(&audit_lost, 0) :
+ atomic_read(&audit_lost);
s.backlog = skb_queue_len(&audit_skb_queue);
s.feature_bitmap = AUDIT_FEATURE_BITMAP_ALL;
s.backlog_wait_time = audit_backlog_wait_time_master;
--
1.7.1
^ permalink raw reply related
* Re: Auditd misses accept syscalls from sshd
From: Steve Grubb @ 2016-12-03 17:47 UTC (permalink / raw)
To: Nathan Cooprider; +Cc: linux-audit
In-Reply-To: <CAMMwpcgW4sbNYMnhUNfLAAgoH9W=Cni+LjFAJ0cYoep0QNyfXg@mail.gmail.com>
On Saturday, December 3, 2016 2:11:04 AM EST Nathan Cooprider wrote:
> Hi! It sounds like I'm missing something obvious!
>
> On Fri, Dec 2, 2016 at 5:13 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > Hello,
> >
> > Addressing a couple obvious things here...
> >
> > On Friday, December 2, 2016 9:55:17 PM EST Nathan Cooprider wrote:
> > > On Fri, Dec 2, 2016 at 4:09 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > > On Friday, December 2, 2016 8:43:46 PM EST Nathan Cooprider wrote:
> > > > > Auditd seems to miss accept syscalls from ssh on Ubuntu 14.
> > > >
> > > > Its not auditd, the kernel does all the work. Auditd acts a lot like a
> > > > specialized syslog. :-)
> > > >
> > > > > I tried versions 2.3.2 and 2.4.5 of the daemon
> >
> > Support was not added until 2.5.
>
> Support for what?
Audit by executable. In the example that I gave I showed the syntax for how
you would audit accept only for sshd. I presume that you are not auditing
accept across the whole system. What rule are you using to audit accept?
> Auditing the accept syscall? What do you mean by "support?" Those are auditd
> versions that I'm talking about. Is that what you mean? Sorry if I was not
> clear. What did it do with accept syscalls before then? I do not see this
> reflected in the changelog
Let's take a look at how you are auditing it and maybe that will explain a few
things. Also, does Ubuntu 14 use upstart or systemd? And perhaps for good
measure include just 1 event when it does work.
-Steve
> https://people.redhat.com/sgrubb/audit/ChangeLog
>
> > > > with kernel versions 3.13.0-96
> >
> > Definitely won't support it.
>
> Support what?
>
> > > > > and 4.4.0-47.
> >
> > The feature landed in 4.3, so 4.4 should have it. However, you need audit
> > 2.5
> > or later to use the kernel feature.
>
> What feature are you talking about? This sounds like it could be the issue,
> but I am not sure to what you are actually referring.
>
> > > I just tried again and had the same problem:
> > > vagrant@vagrant:~$ uname -a
> > > Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24
> > > 19:22:30
> > > UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> >
> > Try pairing that with a newer auditd so that auditctl has the support to
> > load
> > the rule.
>
> I'll check this out. My initial attempts to compile more recent versions
> than 2.4.5 on the newer kernel in Ubuntu 14 had issues, but those are
> probably personal problems.
>
> > -Steve
> >
> > > That's a newer version than I have on my Ubuntu 16 VM, which does
> > > demonstrate the problem. It's also strange that restarting ssh then
> > > makes
> > > the accept syscall events show up. Other sshd syscalls show up in auditd
> > > before and after the ssh restart.
^ permalink raw reply
* Re: Auditd misses accept syscalls from sshd
From: Steve Grubb @ 2016-12-03 17:39 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <op.yrvawl0c1jp0b1@hassan-t420>
On Friday, December 2, 2016 3:44:35 PM EST Hassan Sultan wrote:
> On Fri, 02 Dec 2016 13:42:02 -0800, Nathan Cooprider
>
> <ncooprider@yankeehacker.com> wrote:
> > Thanks for the suggestion. I'm getting other audit events from sshd
> > without restarting ssh. It's just the accept syscalls that do not show
> > up until after I >restart ssh:
> >
> > type=SYSCALL msg=audit(1480714641.465:54): arch=c000003e syscall=43
> > success=yes exit=5 a0=3 a1=7ffce3b031b0 a2=7ffce3b0319c a3=0 items=0
> >
> > >ppid=1 pid=2602 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
> >
> > egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
> > exe="/usr/sbin/>sshd" key=(null)
> >
> > I think that indicates the kernel is sending up audit messages. My
> > question is why the above message fails to come up until after I've
> > restarted ssh.
>
> (I was the person having that issue almost 2 years ago)
>
> I never fully investigated it, but came up with one theory explaining it :
>
> - accept is a blocking syscall , it might be that sshd started and the
> syscall was initiated before the audit rule was loaded. This would explain
> why you see the event when restarting sshd.
Because accept can block, sockets are almost always turned non-blocking when
setting up the listen queue. Then you wait in select/poll/epoll for it to be
ready to accept. And inspection of sshd's code and some stracing shows this to
be the case.
> Don't use the tcp connection time to evaluate whether the auditing worked
> properly, but rather when the initial accept call was made, which
> basically amounts to when sshd is started.
On most systems, auditd starts just before or after syslog. Networking daemons
usually come later in the boot process.
-Steve
^ permalink raw reply
* Re: Auditd misses accept syscalls from sshd
From: Nathan Cooprider @ 2016-12-03 2:15 UTC (permalink / raw)
To: Hassan Sultan; +Cc: linux-audit
In-Reply-To: <op.yrvawl0c1jp0b1@hassan-t420>
[-- Attachment #1.1: Type: text/plain, Size: 1714 bytes --]
On Fri, Dec 2, 2016 at 6:44 PM Hassan Sultan <hsultan@thefroid.net> wrote:
> On Fri, 02 Dec 2016 13:42:02 -0800, Nathan Cooprider <
> ncooprider@yankeehacker.com> wrote:
>
>
>
> Thanks for the suggestion. I'm getting other audit events from sshd
> without restarting ssh. It's just the accept syscalls that do not show up
> until after I restart ssh:
>
> type=SYSCALL msg=audit(1480714641.465:54): arch=c000003e syscall=43
> success=yes exit=5 a0=3 a1=7ffce3b031b0 a2=7ffce3b0319c a3=0 items=0 ppid=1
> pid=2602 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd"
> key=(null)
>
> I think that indicates the kernel is sending up audit messages. My
> question is why the above message fails to come up until after I've
> restarted ssh.
>
>
> (I was the person having that issue almost 2 years ago)
>
> I never fully investigated it, but came up with one theory explaining it :
>
> - accept is a blocking syscall , it might be that sshd started and the
> syscall was initiated before the audit rule was loaded. This would explain
> why you see the event when restarting sshd.
>
> Don't use the tcp connection time to evaluate whether the auditing worked
> properly, but rather when the initial accept call was made, which basically
> amounts to when sshd is started.
>
>
> Hassan
>
After I restart the ssh service I get an accept call every time I try to
ssh into the box, whereas before I restart the ssh service I get no events.
That does not conform with my mental model of how this would work, but I
wouldn't be asking this question if my mental model was correct!
Thanks for the hypothesis and tip, plus the original question!
[-- Attachment #1.2: Type: text/html, Size: 3200 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Auditd misses accept syscalls from sshd
From: Nathan Cooprider @ 2016-12-03 2:11 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <3309840.oCxPxWEFuR@x2>
[-- Attachment #1.1: Type: text/plain, Size: 2125 bytes --]
Hi! It sounds like I'm missing something obvious!
On Fri, Dec 2, 2016 at 5:13 PM Steve Grubb <sgrubb@redhat.com> wrote:
> Hello,
>
> Addressing a couple obvious things here...
>
> On Friday, December 2, 2016 9:55:17 PM EST Nathan Cooprider wrote:
> > On Fri, Dec 2, 2016 at 4:09 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > On Friday, December 2, 2016 8:43:46 PM EST Nathan Cooprider wrote:
> > > > Auditd seems to miss accept syscalls from ssh on Ubuntu 14.
> > >
> > > Its not auditd, the kernel does all the work. Auditd acts a lot like a
> > > specialized syslog. :-)
> > >
> > > > I tried versions 2.3.2 and 2.4.5 of the daemon
>
> Support was not added until 2.5.
>
Support for what? Auditing the accept syscall? What do you mean by
"support?" Those are auditd versions that I'm talking about. Is that what
you mean? Sorry if I was not clear. What did it do with accept syscalls
before then? I do not see this reflected in the changelog
https://people.redhat.com/sgrubb/audit/ChangeLog
> > > with kernel versions 3.13.0-96
>
> Definitely won't support it.
>
Support what?
> > > > and 4.4.0-47.
>
> The feature landed in 4.3, so 4.4 should have it. However, you need audit
> 2.5
> or later to use the kernel feature.
>
What feature are you talking about? This sounds like it could be the issue,
but I am not sure to what you are actually referring.
> > I just tried again and had the same problem:
> >
> > vagrant@vagrant:~$ uname -a
> > Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 19:22:30
> > UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> Try pairing that with a newer auditd so that auditctl has the support to
> load
> the rule.
>
I'll check this out. My initial attempts to compile more recent versions
than 2.4.5 on the newer kernel in Ubuntu 14 had issues, but those are
probably personal problems.
> -Steve
>
> > That's a newer version than I have on my Ubuntu 16 VM, which does
> > demonstrate the problem. It's also strange that restarting ssh then makes
> > the accept syscall events show up. Other sshd syscalls show up in auditd
> > before and after the ssh restart.
>
[-- Attachment #1.2: Type: text/html, Size: 4052 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Auditd misses accept syscalls from sshd
From: Hassan Sultan @ 2016-12-02 23:44 UTC (permalink / raw)
To: Paul Moore, Nathan Cooprider; +Cc: linux-audit
In-Reply-To: <CAMMwpchN9FM2DCtH_JLb7UNfZ80FywgMdU_kjuXEBiiWF3px=w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1281 bytes --]
On Fri, 02 Dec 2016 13:42:02 -0800, Nathan Cooprider
<ncooprider@yankeehacker.com> wrote:
>
>
> Thanks for the suggestion. I'm getting other audit events from sshd
> without restarting ssh. It's just the accept syscalls that do not show
> up until after I >restart ssh:
>
> type=SYSCALL msg=audit(1480714641.465:54): arch=c000003e syscall=43
> success=yes exit=5 a0=3 a1=7ffce3b031b0 a2=7ffce3b0319c a3=0 items=0
> >ppid=1 pid=2602 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
> egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
> exe="/usr/sbin/>sshd" key=(null)
>
> I think that indicates the kernel is sending up audit messages. My
> question is why the above message fails to come up until after I've
> restarted ssh.
>
(I was the person having that issue almost 2 years ago)
I never fully investigated it, but came up with one theory explaining it :
- accept is a blocking syscall , it might be that sshd started and the
syscall was initiated before the audit rule was loaded. This would explain
why you see the event when restarting sshd.
Don't use the tcp connection time to evaluate whether the auditing worked
properly, but rather when the initial accept call was made, which
basically amounts to when sshd is started.
Hassan
[-- Attachment #1.2.1: Type: text/html, Size: 1781 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Auditd misses accept syscalls from sshd
From: Steve Grubb @ 2016-12-02 22:13 UTC (permalink / raw)
To: Nathan Cooprider; +Cc: linux-audit
In-Reply-To: <CAMMwpciFh5f+HHQEf9pfU5528koKK65zAFPVF5UHQBH3NswGLA@mail.gmail.com>
Hello,
Addressing a couple obvious things here...
On Friday, December 2, 2016 9:55:17 PM EST Nathan Cooprider wrote:
> On Fri, Dec 2, 2016 at 4:09 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > On Friday, December 2, 2016 8:43:46 PM EST Nathan Cooprider wrote:
> > > Auditd seems to miss accept syscalls from ssh on Ubuntu 14.
> >
> > Its not auditd, the kernel does all the work. Auditd acts a lot like a
> > specialized syslog. :-)
> >
> > > I tried versions 2.3.2 and 2.4.5 of the daemon
Support was not added until 2.5.
> > > with kernel versions 3.13.0-96
Definitely won't support it.
> > > and 4.4.0-47.
The feature landed in 4.3, so 4.4 should have it. However, you need audit 2.5
or later to use the kernel feature.
> I just tried again and had the same problem:
>
> vagrant@vagrant:~$ uname -a
> Linux vagrant 4.4.0-51-generic #72~14.04.1-Ubuntu SMP Thu Nov 24 19:22:30
> UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Try pairing that with a newer auditd so that auditctl has the support to load
the rule.
-Steve
> That's a newer version than I have on my Ubuntu 16 VM, which does
> demonstrate the problem. It's also strange that restarting ssh then makes
> the accept syscall events show up. Other sshd syscalls show up in auditd
> before and after the ssh restart.
^ permalink raw reply
* Re: [PATCH] audit: remove the audit freelist
From: Paul Moore @ 2016-12-02 21:59 UTC (permalink / raw)
To: Florian Westphal; +Cc: linux-kernel, linux-audit, Eric Paris
In-Reply-To: <20161202000904.GA31010@breakpoint.cc>
On Thu, Dec 1, 2016 at 7:09 PM, Florian Westphal <fw@strlen.de> wrote:
> Paul Moore <paul@paul-moore.com> wrote:
>> On Wed, Nov 30, 2016 at 8:44 PM, Florian Westphal <fw@strlen.de> wrote:
>> > Paul Moore <paul@paul-moore.com> wrote:
>> >> On Tue, Nov 15, 2016 at 8:16 AM, Florian Westphal <fw@strlen.de> wrote:
>> >> > allows better debugging as freeing audit buffers now always honors slub
>> >> > debug hooks (e.g. object poisoning) and leak checker can detect the
>> >> > free operation.
>> >> >
>> >> > Removal also results in a small speedup (using
>> >> > single rule 'iptables -A INPUT -i lo -j AUDIT --type drop'):
>> >> >
>> >> > super_netperf 4 -H 127.0.0.1 -l 360 -t UDP_RR -- -R 1 -m 64
>> >> > Before:
>> >> > 294953
>> >> > After:
>> >> > 298013
>> >> >
>> >> > (alloc/free no longer serializes on spinlock, allocator can use percpu
>> >> > pool).
>> >> >
>> >> > Signed-off-by: Florian Westphal <fw@strlen.de>
>> >> > ---
>> >> > kernel/audit.c | 53 ++++++++---------------------------------------------
>> >> > 1 file changed, 8 insertions(+), 45 deletions(-)
>> >>
>> >> Sorry for the delay, I was hoping to have some time to play around
>> >> with this and offer a more meaningful comment ... I've often wondered
>> >> about converting audit_buffer, and audit_context for that matter, over
>> >> to their own kmem_cache; have you considered that? Or was this
>> >> proposed due to simplicity?
>> >
>> > Not sure I understand, you could still convert it on top of this.
>> > (Although audit_buffer is just 24 bytes after this patch so it will
>> > come from 32byte kmalloc slab).
>>
>> I'm not arguing against this patch, partly just musing out loud,
>> partly just seeing if you had experimented with creating a
>> audit_buffer specific kmem_cache (I'm guessing the answer here is
>> "no"). If we do convert to a kmem_cache this patch would be the
>> obvious first step.
>
> It does convert to a kmem_cache, indirectly.
>
> kmalloc() uses builtin_constant_size() magic to resolve the kmalloc to
> kmem_cache_alloc, using the precreated kmalloc_caches[] in slab_common.c .
Yes, understood, I just think there may be some advantages (tracking,
etc.) to using a dedicated audit_buffer kmem_cache rather than the
system wide bucket.
--
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