* ANN: Experimental Fedora Rawhide kernels (selinux-next and audit-next)
From: Paul Moore @ 2015-11-20 21:49 UTC (permalink / raw)
To: selinux, linux-audit; +Cc: linux-security-module
For the past few weeks I've been building experimental Fedora Rawhide kernels
with all of the SELinux and audit kernel patches targeted for linux-next
included. It has worked out reasonably well, and with the exception of getting
a working Linux 4.4-rc1 build this week, it has proven to be relatively easy
to manage. If you would like to help with testing and don't mind the
instability that comes with development kernels, the Fedora COPR repository
link is below.
I've been doing at least one build each week, sometimes more, and I expect to
continue with that frequency. I also perform a quick sanity check on each
successful build, including running the SELinux and audit testsuites; however,
there may be times when the kernel is simply broken, so exercise caution and
please don't run these kernels on anything critical.
* https://copr.fedoraproject.org/coprs/pcmoore/kernel-secnext
--
paul moore
www.paul-moore.com
^ permalink raw reply
* [RFC PATCH] audit: force seccomp event logging to honor the audit_enabled flag
From: Paul Moore @ 2015-11-23 22:20 UTC (permalink / raw)
To: linux-audit; +Cc: linux-security-module, Tony Jones
Previously we were emitting seccomp audit records regardless of the
audit_enabled setting, a deparature from the rest of audit. This
patch makes seccomp auditing consistent with the rest of the audit
record generation code in that when audit_enabled=0 nothing is logged
by the audit subsystem.
The bulk of this patch is moving the CONFIG_AUDIT block ahead of the
CONFIG_AUDITSYSCALL block in include/linux/audit.h; the only real
code change was in the audit_seccomp() definition.
Reported-by: Tony Jones <tonyj@suse.de>
Signed-off-by: Paul Moore <pmoore@redhat.com>
---
include/linux/audit.h | 204 +++++++++++++++++++++++++------------------------
1 file changed, 104 insertions(+), 100 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 20eba1e..476bc12 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -113,6 +113,107 @@ struct filename;
extern void audit_log_session_info(struct audit_buffer *ab);
+#ifdef CONFIG_AUDIT
+/* These are defined in audit.c */
+ /* Public API */
+extern __printf(4, 5)
+void audit_log(struct audit_context *ctx, gfp_t gfp_mask, int type,
+ const char *fmt, ...);
+
+extern struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask, int type);
+extern __printf(2, 3)
+void audit_log_format(struct audit_buffer *ab, const char *fmt, ...);
+extern void audit_log_end(struct audit_buffer *ab);
+extern bool audit_string_contains_control(const char *string,
+ size_t len);
+extern void audit_log_n_hex(struct audit_buffer *ab,
+ const unsigned char *buf,
+ size_t len);
+extern void audit_log_n_string(struct audit_buffer *ab,
+ const char *buf,
+ size_t n);
+extern void audit_log_n_untrustedstring(struct audit_buffer *ab,
+ const char *string,
+ size_t n);
+extern void audit_log_untrustedstring(struct audit_buffer *ab,
+ const char *string);
+extern void audit_log_d_path(struct audit_buffer *ab,
+ const char *prefix,
+ const struct path *path);
+extern void audit_log_key(struct audit_buffer *ab,
+ char *key);
+extern void audit_log_link_denied(const char *operation,
+ struct path *link);
+extern void audit_log_lost(const char *message);
+#ifdef CONFIG_SECURITY
+extern void audit_log_secctx(struct audit_buffer *ab, u32 secid);
+#else
+static inline void audit_log_secctx(struct audit_buffer *ab, u32 secid)
+{ }
+#endif
+
+extern int audit_log_task_context(struct audit_buffer *ab);
+extern void audit_log_task_info(struct audit_buffer *ab,
+ struct task_struct *tsk);
+
+extern int audit_update_lsm_rules(void);
+
+ /* Private API (for audit.c only) */
+extern int audit_filter_user(int type);
+extern int audit_filter_type(int type);
+extern int audit_rule_change(int type, __u32 portid, int seq,
+ void *data, size_t datasz);
+extern int audit_list_rules_send(struct sk_buff *request_skb, int seq);
+
+extern u32 audit_enabled;
+#else /* CONFIG_AUDIT */
+static inline __printf(4, 5)
+void audit_log(struct audit_context *ctx, gfp_t gfp_mask, int type,
+ const char *fmt, ...)
+{ }
+static inline struct audit_buffer *audit_log_start(struct audit_context *ctx,
+ gfp_t gfp_mask, int type)
+{
+ return NULL;
+}
+static inline __printf(2, 3)
+void audit_log_format(struct audit_buffer *ab, const char *fmt, ...)
+{ }
+static inline void audit_log_end(struct audit_buffer *ab)
+{ }
+static inline void audit_log_n_hex(struct audit_buffer *ab,
+ const unsigned char *buf, size_t len)
+{ }
+static inline void audit_log_n_string(struct audit_buffer *ab,
+ const char *buf, size_t n)
+{ }
+static inline void audit_log_n_untrustedstring(struct audit_buffer *ab,
+ const char *string, size_t n)
+{ }
+static inline void audit_log_untrustedstring(struct audit_buffer *ab,
+ const char *string)
+{ }
+static inline void audit_log_d_path(struct audit_buffer *ab,
+ const char *prefix,
+ const struct path *path)
+{ }
+static inline void audit_log_key(struct audit_buffer *ab, char *key)
+{ }
+static inline void audit_log_link_denied(const char *string,
+ const struct path *link)
+{ }
+static inline void audit_log_secctx(struct audit_buffer *ab, u32 secid)
+{ }
+static inline int audit_log_task_context(struct audit_buffer *ab)
+{
+ return 0;
+}
+static inline void audit_log_task_info(struct audit_buffer *ab,
+ struct task_struct *tsk)
+{ }
+#define audit_enabled 0
+#endif /* CONFIG_AUDIT */
+
#ifdef CONFIG_AUDIT_COMPAT_GENERIC
#define audit_is_compat(arch) (!((arch) & __AUDIT_ARCH_64BIT))
#else
@@ -212,6 +313,9 @@ void audit_core_dumps(long signr);
static inline void audit_seccomp(unsigned long syscall, long signr, int code)
{
+ if (!audit_enabled)
+ return;
+
/* Force a record to be reported if a signal was delivered. */
if (signr || unlikely(!audit_dummy_context()))
__audit_seccomp(syscall, signr, code);
@@ -446,106 +550,6 @@ static inline bool audit_loginuid_set(struct task_struct *tsk)
return uid_valid(audit_get_loginuid(tsk));
}
-#ifdef CONFIG_AUDIT
-/* These are defined in audit.c */
- /* Public API */
-extern __printf(4, 5)
-void audit_log(struct audit_context *ctx, gfp_t gfp_mask, int type,
- const char *fmt, ...);
-
-extern struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask, int type);
-extern __printf(2, 3)
-void audit_log_format(struct audit_buffer *ab, const char *fmt, ...);
-extern void audit_log_end(struct audit_buffer *ab);
-extern bool audit_string_contains_control(const char *string,
- size_t len);
-extern void audit_log_n_hex(struct audit_buffer *ab,
- const unsigned char *buf,
- size_t len);
-extern void audit_log_n_string(struct audit_buffer *ab,
- const char *buf,
- size_t n);
-extern void audit_log_n_untrustedstring(struct audit_buffer *ab,
- const char *string,
- size_t n);
-extern void audit_log_untrustedstring(struct audit_buffer *ab,
- const char *string);
-extern void audit_log_d_path(struct audit_buffer *ab,
- const char *prefix,
- const struct path *path);
-extern void audit_log_key(struct audit_buffer *ab,
- char *key);
-extern void audit_log_link_denied(const char *operation,
- struct path *link);
-extern void audit_log_lost(const char *message);
-#ifdef CONFIG_SECURITY
-extern void audit_log_secctx(struct audit_buffer *ab, u32 secid);
-#else
-static inline void audit_log_secctx(struct audit_buffer *ab, u32 secid)
-{ }
-#endif
-
-extern int audit_log_task_context(struct audit_buffer *ab);
-extern void audit_log_task_info(struct audit_buffer *ab,
- struct task_struct *tsk);
-
-extern int audit_update_lsm_rules(void);
-
- /* Private API (for audit.c only) */
-extern int audit_filter_user(int type);
-extern int audit_filter_type(int type);
-extern int audit_rule_change(int type, __u32 portid, int seq,
- void *data, size_t datasz);
-extern int audit_list_rules_send(struct sk_buff *request_skb, int seq);
-
-extern u32 audit_enabled;
-#else /* CONFIG_AUDIT */
-static inline __printf(4, 5)
-void audit_log(struct audit_context *ctx, gfp_t gfp_mask, int type,
- const char *fmt, ...)
-{ }
-static inline struct audit_buffer *audit_log_start(struct audit_context *ctx,
- gfp_t gfp_mask, int type)
-{
- return NULL;
-}
-static inline __printf(2, 3)
-void audit_log_format(struct audit_buffer *ab, const char *fmt, ...)
-{ }
-static inline void audit_log_end(struct audit_buffer *ab)
-{ }
-static inline void audit_log_n_hex(struct audit_buffer *ab,
- const unsigned char *buf, size_t len)
-{ }
-static inline void audit_log_n_string(struct audit_buffer *ab,
- const char *buf, size_t n)
-{ }
-static inline void audit_log_n_untrustedstring(struct audit_buffer *ab,
- const char *string, size_t n)
-{ }
-static inline void audit_log_untrustedstring(struct audit_buffer *ab,
- const char *string)
-{ }
-static inline void audit_log_d_path(struct audit_buffer *ab,
- const char *prefix,
- const struct path *path)
-{ }
-static inline void audit_log_key(struct audit_buffer *ab, char *key)
-{ }
-static inline void audit_log_link_denied(const char *string,
- const struct path *link)
-{ }
-static inline void audit_log_secctx(struct audit_buffer *ab, u32 secid)
-{ }
-static inline int audit_log_task_context(struct audit_buffer *ab)
-{
- return 0;
-}
-static inline void audit_log_task_info(struct audit_buffer *ab,
- struct task_struct *tsk)
-{ }
-#define audit_enabled 0
-#endif /* CONFIG_AUDIT */
static inline void audit_log_string(struct audit_buffer *ab, const char *buf)
{
audit_log_n_string(ab, buf, strlen(buf));
^ permalink raw reply related
* Re: [RFC PATCH] audit: force seccomp event logging to honor the audit_enabled flag
From: Tony Jones @ 2015-11-23 22:20 UTC (permalink / raw)
To: Paul Moore, linux-audit; +Cc: linux-security-module
In-Reply-To: <20151123222006.15340.18040.stgit@localhost>
On 11/23/2015 02:20 PM, Paul Moore wrote:
> Previously we were emitting seccomp audit records regardless of the
> audit_enabled setting, a deparature from the rest of audit. This
> patch makes seccomp auditing consistent with the rest of the audit
> record generation code in that when audit_enabled=0 nothing is logged
> by the audit subsystem.
>
> The bulk of this patch is moving the CONFIG_AUDIT block ahead of the
> CONFIG_AUDITSYSCALL block in include/linux/audit.h; the only real
> code change was in the audit_seccomp() definition.
>
> Reported-by: Tony Jones <tonyj@suse.de>
> Signed-off-by: Paul Moore <pmoore@redhat.com>
Seems pretty much the same (functionally) as the patch I posted to audit
list on 10/12/2015 except that didn't hoist the entire block.
Signed-off-by: Tony Jones <tonyj@suse.de>
^ permalink raw reply
* Re: [RFC PATCH] audit: force seccomp event logging to honor the audit_enabled flag
From: Paul Moore @ 2015-11-23 22:35 UTC (permalink / raw)
To: Tony Jones; +Cc: Paul Moore, linux-audit, linux-security-module
In-Reply-To: <56539144.6000008@suse.de>
On Mon, Nov 23, 2015 at 5:20 PM, Tony Jones <tonyj@suse.de> wrote:
> On 11/23/2015 02:20 PM, Paul Moore wrote:
>> Previously we were emitting seccomp audit records regardless of the
>> audit_enabled setting, a deparature from the rest of audit. This
>> patch makes seccomp auditing consistent with the rest of the audit
>> record generation code in that when audit_enabled=0 nothing is logged
>> by the audit subsystem.
>>
>> The bulk of this patch is moving the CONFIG_AUDIT block ahead of the
>> CONFIG_AUDITSYSCALL block in include/linux/audit.h; the only real
>> code change was in the audit_seccomp() definition.
>>
>> Reported-by: Tony Jones <tonyj@suse.de>
>> Signed-off-by: Paul Moore <pmoore@redhat.com>
>
> Seems pretty much the same (functionally) as the patch I posted to audit
> list on 10/12/2015 except that didn't hoist the entire block.
Yep, I prefered to move the block as I think it should have been that
way anyway from the start. IMHO we got to many audit Kconfig knobs
as-is and splitting that block for just the audit_enabled flag made
things worse.
> Signed-off-by: Tony Jones <tonyj@suse.de>
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Fold CONFIG_AUDITSYSCALL into CONFIG_AUDIT?
From: Paul Moore @ 2015-11-23 22:42 UTC (permalink / raw)
To: linux-audit
Does anyone out there build kernels with CONFIG_AUDIT=y and
CONFIG_AUDITSYSCALL=n? I'm thinking of simply removing the
CONFIG_AUDITSYSCALL knob and moving all that code under CONFIG_AUDIT,
does anyone have any objections?
--
paul moore
www.paul-moore.com
^ permalink raw reply
* RE: EXT :Fold CONFIG_AUDITSYSCALL into CONFIG_AUDIT?
From: Boyce, Kevin P (AS) @ 2015-11-24 13:58 UTC (permalink / raw)
To: Paul Moore, linux-audit@redhat.com
In-Reply-To: <CAHC9VhTfWjC2VLVgOrPPJZa_fDacdZ_cMT2CG5yLio6AX0qJBQ@mail.gmail.com>
Having never looked at the code, it sounds reasonable to me. It doesn't make a lot of sense to disable syscall auditing independently.
Kevin Boyce
-----Original Message-----
From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Paul Moore
Sent: Monday, November 23, 2015 5:43 PM
To: linux-audit@redhat.com
Subject: EXT :Fold CONFIG_AUDITSYSCALL into CONFIG_AUDIT?
Does anyone out there build kernels with CONFIG_AUDIT=y and CONFIG_AUDITSYSCALL=n? I'm thinking of simply removing the CONFIG_AUDITSYSCALL knob and moving all that code under CONFIG_AUDIT, does anyone have any objections?
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: EXT :Fold CONFIG_AUDITSYSCALL into CONFIG_AUDIT?
From: Paul Moore @ 2015-11-24 14:07 UTC (permalink / raw)
To: Boyce, Kevin P (AS); +Cc: linux-audit@redhat.com
In-Reply-To: <97985b6b623c49f1bcf121e1541f268e@XCGVAG30.northgrum.com>
On Tue, Nov 24, 2015 at 8:58 AM, Boyce, Kevin P (AS)
<Kevin.Boyce@ngc.com> wrote:
> Having never looked at the code, it sounds reasonable to me. It doesn't make a lot of sense to disable syscall auditing independently.
I'd be very surprised to hear if anyone is running audit *without*
syscall auditing, but I thought I would toss the question out there on
the off chance I'm missing some critical use case.
> -----Original Message-----
> From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Paul Moore
> Sent: Monday, November 23, 2015 5:43 PM
> To: linux-audit@redhat.com
> Subject: EXT :Fold CONFIG_AUDITSYSCALL into CONFIG_AUDIT?
>
> Does anyone out there build kernels with CONFIG_AUDIT=y and CONFIG_AUDITSYSCALL=n? I'm thinking of simply removing the CONFIG_AUDITSYSCALL knob and moving all that code under CONFIG_AUDIT, does anyone have any objections?
--
paul moore
www.paul-moore.com
^ permalink raw reply
* RE: EXT :Fold CONFIG_AUDITSYSCALL into CONFIG_AUDIT?
From: Boyce, Kevin P (AS) @ 2015-11-24 17:25 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit@redhat.com
In-Reply-To: <CAHC9VhRtVvX6=d7BT24EaCXL9p4hzW1bu99gQOAwtm0dPLF=sA@mail.gmail.com>
Is there an advantage to disabling syscall use like significantly reduced memory usage if someone only needs to do file watches? In the end though I thought everything that was auditable was via syscall.
Kevin Boyce
-----Original Message-----
From: Paul Moore [mailto:paul@paul-moore.com]
Sent: Tuesday, November 24, 2015 9:08 AM
To: Boyce, Kevin P (AS)
Cc: linux-audit@redhat.com
Subject: Re: EXT :Fold CONFIG_AUDITSYSCALL into CONFIG_AUDIT?
On Tue, Nov 24, 2015 at 8:58 AM, Boyce, Kevin P (AS) <Kevin.Boyce@ngc.com> wrote:
> Having never looked at the code, it sounds reasonable to me. It doesn't make a lot of sense to disable syscall auditing independently.
I'd be very surprised to hear if anyone is running audit *without* syscall auditing, but I thought I would toss the question out there on the off chance I'm missing some critical use case.
> -----Original Message-----
> From: linux-audit-bounces@redhat.com
> [mailto:linux-audit-bounces@redhat.com] On Behalf Of Paul Moore
> Sent: Monday, November 23, 2015 5:43 PM
> To: linux-audit@redhat.com
> Subject: EXT :Fold CONFIG_AUDITSYSCALL into CONFIG_AUDIT?
>
> Does anyone out there build kernels with CONFIG_AUDIT=y and CONFIG_AUDITSYSCALL=n? I'm thinking of simply removing the CONFIG_AUDITSYSCALL knob and moving all that code under CONFIG_AUDIT, does anyone have any objections?
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: EXT :Fold CONFIG_AUDITSYSCALL into CONFIG_AUDIT?
From: Paul Moore @ 2015-11-24 18:03 UTC (permalink / raw)
To: Boyce, Kevin P (AS); +Cc: linux-audit@redhat.com
In-Reply-To: <822a6380c92247b6861b56d8ff8ec1d4@XCGVAG30.northgrum.com>
On Tue, Nov 24, 2015 at 12:25 PM, Boyce, Kevin P (AS)
<Kevin.Boyce@ngc.com> wrote:
> Is there an advantage to disabling syscall use like significantly reduced memory usage if someone only needs to do file watches? In the end though I thought everything that was auditable was via syscall.
You would save on kernel image size (code is compiled out) and
possibly some performance gains, but I'm not entirely sure of that
last point, I would need to go check the code a bit more. However, I
think the better question is, how useful are file watches without the
associated syscall record? I'm going to say "not very". Also, it is
probably moot, because as we mentioned earlier, I just don't believe
there is anyone using audit who disables syscall auditing - it just
doesn't make much sense.
> -----Original Message-----
> From: Paul Moore [mailto:paul@paul-moore.com]
> Sent: Tuesday, November 24, 2015 9:08 AM
> To: Boyce, Kevin P (AS)
> Cc: linux-audit@redhat.com
> Subject: Re: EXT :Fold CONFIG_AUDITSYSCALL into CONFIG_AUDIT?
>
> On Tue, Nov 24, 2015 at 8:58 AM, Boyce, Kevin P (AS) <Kevin.Boyce@ngc.com> wrote:
>> Having never looked at the code, it sounds reasonable to me. It doesn't make a lot of sense to disable syscall auditing independently.
>
> I'd be very surprised to hear if anyone is running audit *without* syscall auditing, but I thought I would toss the question out there on the off chance I'm missing some critical use case.
>
>> -----Original Message-----
>> From: linux-audit-bounces@redhat.com
>> [mailto:linux-audit-bounces@redhat.com] On Behalf Of Paul Moore
>> Sent: Monday, November 23, 2015 5:43 PM
>> To: linux-audit@redhat.com
>> Subject: EXT :Fold CONFIG_AUDITSYSCALL into CONFIG_AUDIT?
>>
>> Does anyone out there build kernels with CONFIG_AUDIT=y and CONFIG_AUDITSYSCALL=n? I'm thinking of simply removing the CONFIG_AUDITSYSCALL knob and moving all that code under CONFIG_AUDIT, does anyone have any objections?
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH] audit: force seccomp event logging to honor the audit_enabled flag
From: Paul Moore @ 2015-11-24 18:57 UTC (permalink / raw)
To: linux-audit; +Cc: Tony Jones, linux-security-module
In-Reply-To: <CAHC9VhSSFU_Sov+Q7fZESOnHOA6-rNOQVLahiiwOB7gfAqovBw@mail.gmail.com>
On Monday, November 23, 2015 05:35:58 PM Paul Moore wrote:
> On Mon, Nov 23, 2015 at 5:20 PM, Tony Jones <tonyj@suse.de> wrote:
> > On 11/23/2015 02:20 PM, Paul Moore wrote:
> >> Previously we were emitting seccomp audit records regardless of the
> >> audit_enabled setting, a deparature from the rest of audit. This
> >> patch makes seccomp auditing consistent with the rest of the audit
> >> record generation code in that when audit_enabled=0 nothing is logged
> >> by the audit subsystem.
> >>
> >> The bulk of this patch is moving the CONFIG_AUDIT block ahead of the
> >> CONFIG_AUDITSYSCALL block in include/linux/audit.h; the only real
> >> code change was in the audit_seccomp() definition.
> >>
> >> Reported-by: Tony Jones <tonyj@suse.de>
> >> Signed-off-by: Paul Moore <pmoore@redhat.com>
> >
> > Seems pretty much the same (functionally) as the patch I posted to audit
> > list on 10/12/2015 except that didn't hoist the entire block.
>
> Yep, I prefered to move the block as I think it should have been that
> way anyway from the start. IMHO we got to many audit Kconfig knobs
> as-is and splitting that block for just the audit_enabled flag made
> things worse.
>
> > Signed-off-by: Tony Jones <tonyj@suse.de>
I just merged this patch into audit#next, the only change is I replaced the
"Reported-by" for Tony with his sign-off.
--
paul moore
security @ redhat
^ permalink raw reply
* RE: Audit Framework and namespaces
From: Gulland, Scott A @ 2015-12-08 4:14 UTC (permalink / raw)
To: Richard Guy Briggs, Gulland, Scott A; +Cc: linux-audit@redhat.com
In-Reply-To: <20151103194425.GF1422@madcap2.tricolour.ca>
Thanks Richard.
Your answer was indeed helpful. I was assigned to work on Open Switch in late October and to investigate providing an audit trail feature. Open Switch is a Linux based embedded Network Operating System. After some resource on audit functionality on Linux, the obvious choice was to leverage the Audit Framework. There was a question raised as to whether there was a name space incompatibility, but since Open Switch only uses network namespaces, that doesn't appear to be an issue.
What we need to do is log who did what for any operation that changes the switch configuration. We have a variety of ways to modify the switch's configuration; REST, CLI, OVSDB API, and others. We want to use the audit library calls to log these changes. Is this reasonable?
It took a month to get a Open Switch linux image put together that contains the audit framework. I've just started playing with it and have noticed that "auditd" exits with an error when running a docker container. Open Switch uses a docker container with a linux image which has a switch simulator that is used for development. Of course the actual released environment is using real switch hardware on a non-container based linux image. It appears that the audit framework does not work in a docker container. Are there plans to add support for containers or is there some magic instructions for getting auditd to work in a container?
Scott Gulland
916.785.1497
HPE Networking, CEB R&D
-----Original Message-----
From: Richard Guy Briggs [mailto:rgb@redhat.com]
Sent: Tuesday, November 03, 2015 11:44 AM
To: Gulland, Scott A
Cc: linux-audit@redhat.com
Subject: Re: Audit Framework and namespaces
On 15/11/03, Gulland, Scott A wrote:
> Does the audit framework work with linux namespaces?
The quick answer is "Some".
I am not aware of any restrictions on running audit services in MNT, UTS or IPC namespaces. The upstream kernel has support for running auditd in any network namespace. Additionally, processes with CAP_AUDIT_WRITE (generally to send AUDIT_USER_* class messages) can send from any PID namespace, but auditd is not permitted to run anywhere other than in the initial PID namespace. There is no support for any audit services from any USER namespace other than initial due to serious concerns with security, policy and experience still accumulating in that area. There are expectations that this latter will be supported in the future, but that needs planning, execution and thorough testing.
I hope this helps answer your question. I note you didn't ask about audit working in containers, which is a harder question to answer clearly due to the definition of "container". The last point made in the paragraph above will get us closer to supporting audit services in Linux containers.
> Scott Gulland
- 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: Audit Framework and namespaces
From: Richard Guy Briggs @ 2015-12-08 16:10 UTC (permalink / raw)
To: Gulland, Scott A; +Cc: linux-audit@redhat.com
In-Reply-To: <B41870ED03633F4092CDF476119204DF561CBB34@G9W0758.americas.hpqcorp.net>
On 15/12/08, Gulland, Scott A wrote:
> Thanks Richard.
Scott, glad to be of service.
> Your answer was indeed helpful. I was assigned to work on Open Switch
> in late October and to investigate providing an audit trail feature.
> Open Switch is a Linux based embedded Network Operating System.
> After some resource on audit functionality on Linux, the obvious
> choice was to leverage the Audit Framework. There was a question
> raised as to whether there was a name space incompatibility, but since
> Open Switch only uses network namespaces, that doesn't appear to be an
> issue.
So it should just work.
> What we need to do is log who did what for any operation that changes
> the switch configuration. We have a variety of ways to modify the
> switch's configuration; REST, CLI, OVSDB API, and others. We want to
> use the audit library calls to log these changes. Is this
> reasonable?
I don't see a particular problem. Jamal (Hadi Salim) was talking about
something similar for his FORCES work at Mojatatu.
> It took a month to get a Open Switch linux image put together that
> contains the audit framework. I've just started playing with it and
> have noticed that "auditd" exits with an error when running a docker
> container. Open Switch uses a docker container with a linux image
> which has a switch simulator that is used for development. Of
> course the actual released environment is using real switch hardware
> on a non-container based linux image. It appears that the audit
> framework does not work in a docker container. Are there plans to
> add support for containers or is there some magic instructions for
> getting auditd to work in a container?
I assume that docker containers at least spawn a PID namespace and
attempt to use CAP_AUDIT_CONTROL, so that would explain why it won't
work. As outlined in my first reply, there are ideas to support PID
namespaces, but there is no detailed design yet.
Again, the definition of a container comes into it as well, but we think
we have a reasonable understanding of the needs of docker containers and
have an idea how to get there. User namespaces are further off, but I
don't believe they are needed for docker at this point.
> Scott Gulland
> 916.785.1497
> HPE Networking, CEB R&D
>
>
> -----Original Message-----
> From: Richard Guy Briggs [mailto:rgb@redhat.com]
> Sent: Tuesday, November 03, 2015 11:44 AM
> To: Gulland, Scott A
> Cc: linux-audit@redhat.com
> Subject: Re: Audit Framework and namespaces
>
> On 15/11/03, Gulland, Scott A wrote:
> > Does the audit framework work with linux namespaces?
>
> The quick answer is "Some".
>
> I am not aware of any restrictions on running audit services in MNT, UTS or IPC namespaces. The upstream kernel has support for running auditd in any network namespace. Additionally, processes with CAP_AUDIT_WRITE (generally to send AUDIT_USER_* class messages) can send from any PID namespace, but auditd is not permitted to run anywhere other than in the initial PID namespace. There is no support for any audit services from any USER namespace other than initial due to serious concerns with security, policy and experience still accumulating in that area. There are expectations that this latter will be supported in the future, but that needs planning, execution and thorough testing.
>
> I hope this helps answer your question. I note you didn't ask about audit working in containers, which is a harder question to answer clearly due to the definition of "container". The last point made in the paragraph above will get us closer to supporting audit services in Linux containers.
>
> > Scott Gulland
>
> - 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
^ permalink raw reply
* Re: Audit Framework and namespaces
From: Steve Grubb @ 2015-12-08 16:23 UTC (permalink / raw)
To: linux-audit; +Cc: Richard Guy Briggs
In-Reply-To: <20151208161056.GA32667@madcap2.tricolour.ca>
On Tuesday, December 08, 2015 11:10:56 AM Richard Guy Briggs wrote:
> On 15/12/08, Gulland, Scott A wrote:
> > It took a month to get a Open Switch linux image put together that
> > contains the audit framework. I've just started playing with it and
> > have noticed that "auditd" exits with an error when running a docker
> > container. Open Switch uses a docker container with a linux image
> > which has a switch simulator that is used for development. Of
> > course the actual released environment is using real switch hardware
> > on a non-container based linux image. It appears that the audit
> > framework does not work in a docker container. Are there plans to
> > add support for containers or is there some magic instructions for
> > getting auditd to work in a container?
>
> I assume that docker containers at least spawn a PID namespace and
> attempt to use CAP_AUDIT_CONTROL, so that would explain why it won't
> work. As outlined in my first reply, there are ideas to support PID
> namespaces, but there is no detailed design yet.
>
> Again, the definition of a container comes into it as well, but we think
> we have a reasonable understanding of the needs of docker containers and
> have an idea how to get there. User namespaces are further off, but I
> don't believe they are needed for docker at this point.
And further to the point, right now, we don't want events from inside the
container going to the system audit daemon. It potentially has no idea what a
pid, network, uid, gid, or hostname maps to. These have to be resolved inside
the container and then aggregated at the system daemon or datacenter
aggregator.
-Steve
^ permalink raw reply
* [PATCH] audit: always enable syscall auditing when supported and audit is enabled
From: Paul Moore @ 2015-12-08 16:42 UTC (permalink / raw)
To: linux-audit
To the best of our knowledge, everyone who enables audit at compile
time also enables syscall auditing; this patch simplifies the Kconfig
menus by removing the option to disable syscall auditing when audit
is selected and the target arch supports it.
Signed-off-by: Paul Moore <pmoore@redhat.com>
---
init/Kconfig | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index c24b6f7..d4663b1 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -299,20 +299,15 @@ config AUDIT
help
Enable auditing infrastructure that can be used with another
kernel subsystem, such as SELinux (which requires this for
- logging of avc messages output). Does not do system-call
- auditing without CONFIG_AUDITSYSCALL.
+ logging of avc messages output). System call auditing is included
+ on architectures which support it.
config HAVE_ARCH_AUDITSYSCALL
bool
config AUDITSYSCALL
- bool "Enable system-call auditing support"
+ def_bool y
depends on AUDIT && HAVE_ARCH_AUDITSYSCALL
- default y if SECURITY_SELINUX
- help
- Enable low-overhead system-call auditing infrastructure that
- can be used independently or with another kernel subsystem,
- such as SELinux.
config AUDIT_WATCH
def_bool y
^ permalink raw reply related
* New draft standards
From: Steve Grubb @ 2015-12-08 19:22 UTC (permalink / raw)
To: linux-audit
Hello,
I would like to point out 2 new standards that have been posted to the linux
audit web page. The first establishes the events around system start up and
shutdown. This is important because it sets the session boundaries for when a
system is up or down or crashed.
http://people.redhat.com/sgrubb/audit/system-lifecycle.txt
The second standard is more of a forward looking standard. It explains how the
audit daemon and utilities will perform event enrichment before being stored
long term in an aggregator. The target for implementation is the 2.5 release
of the audit daemon.
http://people.redhat.com/sgrubb/audit/event-enrichment
Let me know if anyone has feedback on these standards, especially the second
one.
-Steve
^ permalink raw reply
* Re: New draft standards
From: Paul Moore @ 2015-12-08 19:58 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <3616972.XJnAnOOqWb@x2>
On Tue, Dec 8, 2015 at 2:22 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> Hello,
>
> I would like to point out 2 new standards that have been posted to the linux
> audit web page. The first establishes the events around system start up and
> shutdown. This is important because it sets the session boundaries for when a
> system is up or down or crashed.
>
> http://people.redhat.com/sgrubb/audit/system-lifecycle.txt
>
> The second standard is more of a forward looking standard. It explains how the
> audit daemon and utilities will perform event enrichment before being stored
> long term in an aggregator. The target for implementation is the 2.5 release
> of the audit daemon.
>
> http://people.redhat.com/sgrubb/audit/event-enrichment
>
> Let me know if anyone has feedback on these standards, especially the second
> one.
Were these two specification documents created based on published
standards from an established standards body, e.g. NIST, IETF, etc?
If so, I think it would be helpful for you to reference the published
standard in your documents. If these specifications are an early
draft standard intended to be submitted to a standards body then I
would recommend mentioning the intended group in the document.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: New draft standards
From: Steve Grubb @ 2015-12-08 20:25 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <CAHC9VhSu1J-Zn15E4u2agzO-B1_V5BzOcX7n9HcVTtbRK-arPA@mail.gmail.com>
On Tuesday, December 08, 2015 02:58:18 PM Paul Moore wrote:
> On Tue, Dec 8, 2015 at 2:22 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > Hello,
> >
> > I would like to point out 2 new standards that have been posted to the
> > linux audit web page. The first establishes the events around system
> > start up and shutdown. This is important because it sets the session
> > boundaries for when a system is up or down or crashed.
> >
> > http://people.redhat.com/sgrubb/audit/system-lifecycle.txt
> >
> > The second standard is more of a forward looking standard. It explains how
> > the audit daemon and utilities will perform event enrichment before being
> > stored long term in an aggregator. The target for implementation is the
> > 2.5 release of the audit daemon.
> >
> > http://people.redhat.com/sgrubb/audit/event-enrichment
> >
> > Let me know if anyone has feedback on these standards, especially the
> > second one.
>
> Were these two specification documents created based on published
> standards from an established standards body, e.g. NIST, IETF, etc?
No. All of the standards published to date is documenting what exists and why.
The needs are typically driven by common criteria and the need to detect
certain kinds of events for intrusion detection or anomalous conditions.
> If so, I think it would be helpful for you to reference the published
> standard in your documents. If these specifications are an early
> draft standard intended to be submitted to a standards body then I
> would recommend mentioning the intended group in the document.
No intention of that at this point. The main issue is that we have put a lot
of patches into various utilities. We need other "like" utilities to follow
the same rules. But when you say "follow the same rules", you need some rules
published for them to follow.
The side effect is that third parties can better write analysis programs
without having to reverse engineer what the see in the event stream. They can
go straight to the source and write a program to look for certain things.
-Steve
^ permalink raw reply
* Re: New draft standards
From: Richard Guy Briggs @ 2015-12-08 20:49 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <3616972.XJnAnOOqWb@x2>
On 15/12/08, Steve Grubb wrote:
> Hello,
>
> I would like to point out 2 new standards that have been posted to the linux
> audit web page. The first establishes the events around system start up and
> shutdown. This is important because it sets the session boundaries for when a
> system is up or down or crashed.
>
> http://people.redhat.com/sgrubb/audit/system-lifecycle.txt
A couple of very minor corrections to this first one:
--- system-lifecycle.txt.orig 2015-12-08 15:36:34.441782830 -0500
+++ system-lifecycle.txt 2015-12-08 15:38:10.763998066 -0500
@@ -62,7 +62,7 @@
/* boot */
audit_log_user_message (fd, AUDIT_SYSTEM_BOOT, "init", NULL, NULL, NULL, 1);
-/* run leve change */
+/* run level change */
snprintf (buf, sizeof (buf), "old-level=%c new-level=%c", old, level);
audit_log_user_message (fd, AUDIT_SYSTEM_RUNLEVEL, buf, NULL, NULL, NULL, 1);
@@ -77,7 +77,7 @@
audit_log_user_message (fd, AUDIT_SERVICE_START, buf, NULL, NULL, NULL, 1);
free(buf);
-Service stop events should be the same os start with the exception of using
+Service stop events should be the same as start with the exception of using
AUDIT_SERVICE_STOP as the event type. If only the pid is available, record
that as "spid". There must be a way to compare start and stop records to see
that they balance. (There are as many starts as stops.)
> The second standard is more of a forward looking standard. It explains how the
> audit daemon and utilities will perform event enrichment before being stored
> long term in an aggregator. The target for implementation is the 2.5 release
> of the audit daemon.
>
> http://people.redhat.com/sgrubb/audit/event-enrichment
How do you mean for IP address to be "resolved"? Is this simply a
matter of recording it? Or would this be a reverse lookup on the local
machine to get the opinion of what it should be from the DNS perspective
of the local machine, assuming different machines in the logging domain
could potentially have different views of DNS?
> Let me know if anyone has feedback on these standards, especially the second
> one.
>
> -Steve
- 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] audit: always enable syscall auditing when supported and audit is enabled
From: Richard Guy Briggs @ 2015-12-08 20:50 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <20151208164237.15736.42955.stgit@localhost>
On 15/12/08, Paul Moore wrote:
> To the best of our knowledge, everyone who enables audit at compile
> time also enables syscall auditing; this patch simplifies the Kconfig
> menus by removing the option to disable syscall auditing when audit
> is selected and the target arch supports it.
>
> Signed-off-by: Paul Moore <pmoore@redhat.com>
ACK.
> ---
> init/Kconfig | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index c24b6f7..d4663b1 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -299,20 +299,15 @@ config AUDIT
> help
> Enable auditing infrastructure that can be used with another
> kernel subsystem, such as SELinux (which requires this for
> - logging of avc messages output). Does not do system-call
> - auditing without CONFIG_AUDITSYSCALL.
> + logging of avc messages output). System call auditing is included
> + on architectures which support it.
>
> config HAVE_ARCH_AUDITSYSCALL
> bool
>
> config AUDITSYSCALL
> - bool "Enable system-call auditing support"
> + def_bool y
> depends on AUDIT && HAVE_ARCH_AUDITSYSCALL
> - default y if SECURITY_SELINUX
> - help
> - Enable low-overhead system-call auditing infrastructure that
> - can be used independently or with another kernel subsystem,
> - such as SELinux.
>
> config AUDIT_WATCH
> def_bool y
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* Re: New draft standards
From: Steve Grubb @ 2015-12-08 21:28 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20151208204958.GB32667@madcap2.tricolour.ca>
On Tuesday, December 08, 2015 03:49:58 PM Richard Guy Briggs wrote:
> On 15/12/08, Steve Grubb wrote:
> > Hello,
> >
> > I would like to point out 2 new standards that have been posted to the
> > linux audit web page. The first establishes the events around system
> > start up and shutdown. This is important because it sets the session
> > boundaries for when a system is up or down or crashed.
> >
> > http://people.redhat.com/sgrubb/audit/system-lifecycle.txt
>
> A couple of very minor corrections to this first one:
Thanks, Applied.
> > The second standard is more of a forward looking standard. It explains how
> > the audit daemon and utilities will perform event enrichment before being
> > stored long term in an aggregator. The target for implementation is the
> > 2.5 release of the audit daemon.
> >
> > http://people.redhat.com/sgrubb/audit/event-enrichment
>
> How do you mean for IP address to be "resolved"? Is this simply a
> matter of recording it? Or would this be a reverse lookup on the local
> machine to get the opinion of what it should be from the DNS perspective
> of the local machine, assuming different machines in the logging domain
> could potentially have different views of DNS?
I think the latter. Bot-nets get shut down. Systems go away. Sometimes
internal names differ from external names.
-Steve
> > Let me know if anyone has feedback on these standards, especially the
> > second one.
> >
> > -Steve
>
> - 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: New draft standards
From: Paul Moore @ 2015-12-09 0:28 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <10524337.222XSUgHvY@x2>
On Tuesday, December 08, 2015 03:25:22 PM Steve Grubb wrote:
> On Tuesday, December 08, 2015 02:58:18 PM Paul Moore wrote:
> > On Tue, Dec 8, 2015 at 2:22 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > Hello,
> > >
> > > I would like to point out 2 new standards that have been posted to the
> > > linux audit web page. The first establishes the events around system
> > > start up and shutdown. This is important because it sets the session
> > > boundaries for when a system is up or down or crashed.
> > >
> > > http://people.redhat.com/sgrubb/audit/system-lifecycle.txt
> > >
> > > The second standard is more of a forward looking standard. It explains
> > > how
> > > the audit daemon and utilities will perform event enrichment before
> > > being
> > > stored long term in an aggregator. The target for implementation is the
> > > 2.5 release of the audit daemon.
> > >
> > > http://people.redhat.com/sgrubb/audit/event-enrichment
> > >
> > > Let me know if anyone has feedback on these standards, especially the
> > > second one.
> >
> > Were these two specification documents created based on published
> > standards from an established standards body, e.g. NIST, IETF, etc?
>
> No. All of the standards published to date is documenting what exists and
> why. The needs are typically driven by common criteria and the need to
> detect certain kinds of events for intrusion detection or anomalous
> conditions.
Okay, let's not call these "standards" and just stick with "specifications".
The term standards has all sorts of connotations associated with it, both good
and bad, and I think we should be clear when we start talking with other
developers. I think it would also be *very* helpful if you could explain the
motivation behind these specs so we understand what problems you are trying to
solve and what requirements you are trying to meet; you talk about this a bit
in the conclusion, but more background would be nice.
Another nit-picky comment, in the future I would suggest sending the specs
inline in your mail; having to go to my browser to read your document and then
cut-and-paste it into my email to comment on it means your request for
feedback goes to the bottom of my todo list. Lower the bar for collaboration
as much as possible, if you inline the text all we have to do is hit "reply"
to comment on the specs.
Anyway, on to your docs ...
* https://people.redhat.com/sgrubb/audit/system-lifecycle.txt
> System Lifecycle Auditing
> =========================
> This document will go over the events that are associated with starting up
> a system and shutting it down. Knowing what events make up these actions
> allows an analytical application to know the boundaries of all sessions and
> actions a user may perform. It also allows identification of crashed systems
> or malfunctioning services. The following table lists the events that make
> up the system lifecycle in the audit trail:
>
> AUDIT_SYSTEM_BOOT - System boot
> AUDIT_SYSTEM_RUNLEVEL - System runlevel change
> AUDIT_DAEMON_START - Audit daemon startup record
> AUDIT_DAEMON_ABORT - Audit daemon error stop record
> AUDIT_SERVICE_START - Service (daemon) start
> AUDIT_SERVICE_STOP - Service (daemon) stop
> AUDIT_SYSTEM_SHUTDOWN - System shutdown
> AUDIT_DAEMON_END - Audit daemon normal stop record
Why both an AUDIT_DAEMON_ABORT and an AUDIT_DAEMON_END and not just an
AUDIT_DAEMON_STOP with a field to indicate if it was a normal shutdown or a
failure as outlined in the spec? This would be more consistent with the other
daemons and the shutdown result field could potentially be reused by the init
systems for other daemons (assuming the information was conveyed via return
values or some other mechanism).
> Lifecycle of the system
> =======================
> When the system is powered on, control is eventually turned over to an
> init daemon. This daemon is responsible for starting up all other system
> services and performing an order system shutdown when asked. This init
> daemon should send a AUDIT_SYSTEM_BOOT event after it has done its own
> initialization. Most init systems have different targets or modes of
> operation that the system is turned over for interactive sessions. Examples
> are multi-user console, multi-user graphical, etc.
You mention it later, but it might be a good idea to mention in this paragraph
that the audit daemon should be started as early as possible by the init
daemon.
> Init will determine what runlevel the system is ultimately going to try to
> achieve. When gets there or it fails to get there, it shall issue an
> AUDIT_SYSTEM_RUNLEVEL event to denote which mode of operation it was going
> to be in. If an admin requests that the system switch to another runlevel,
> then it should issue another AUDIT_SYSTEM_RUNLEVEL event.
I think it would be good to have a discussion about runlevels that don't
follow the traditional integer numbering, e.g. string based runlevels.
* https://people.redhat.com/sgrubb/audit/event-enrichment
> Audit Event Enrichment
> ======================
>
> There are times when the audit events are stored in another machine and need
> to be searched at a later date. Some parts of the audit event are temporally
> limited in duration or unique to a system. This makes interpretting fields
> that are numbers into human readable fields hard or impossible without
> running a report at the time of the event or on the machine the event
> occurred on.
>
> To address this issue, the audit daemon will get a new mode, enrich, where
> the audit trail will be amended as follows at the time an event is logged:
>
> 1) Translations will be:
> a) appended to the end of the event with the field's name in capital
> letters
Please no, let's leave field names case insensitive, perhaps an agreed upon
suffix, e.g. "-trans"?
> b) encoded if user controlled data is used for enrichment
>
> 2) The auparse library will:
> a) preferentially use these fields whenever an interpretation is requested
> b) if none exist, look up the fields on the local machine if necessary
I think resolving these fields on the local machine is misleading, and
potentially dangerous; this is especially true with respect to SELinux labels.
If you can't resolve the field, simply display it raw and let the operator
determine how to handle it.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: New draft standards
From: Burn Alting @ 2015-12-09 1:43 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <1748716.onoFcfVhek@sifl>
On Tue, 2015-12-08 at 19:28 -0500, Paul Moore wrote:
> On Tuesday, December 08, 2015 03:25:22 PM Steve Grubb wrote:
> > On Tuesday, December 08, 2015 02:58:18 PM Paul Moore wrote:
> > > On Tue, Dec 8, 2015 at 2:22 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > > Hello,
> > > >
> > > > I would like to point out 2 new standards that have been posted to the
> > > > linux audit web page. The first establishes the events around system
> > > > start up and shutdown. This is important because it sets the session
> > > > boundaries for when a system is up or down or crashed.
> > > >
> > > > http://people.redhat.com/sgrubb/audit/system-lifecycle.txt
> > > >
> > > > The second standard is more of a forward looking standard. It explains
> > > > how
> > > > the audit daemon and utilities will perform event enrichment before
> > > > being
> > > > stored long term in an aggregator. The target for implementation is the
> > > > 2.5 release of the audit daemon.
> > > >
> > > > http://people.redhat.com/sgrubb/audit/event-enrichment
> > > >
> > > > Let me know if anyone has feedback on these standards, especially the
> > > > second one.
> > >
> > > Were these two specification documents created based on published
> > > standards from an established standards body, e.g. NIST, IETF, etc?
> >
> > No. All of the standards published to date is documenting what exists and
> > why. The needs are typically driven by common criteria and the need to
> > detect certain kinds of events for intrusion detection or anomalous
> > conditions.
>
> Okay, let's not call these "standards" and just stick with "specifications".
> The term standards has all sorts of connotations associated with it, both good
> and bad, and I think we should be clear when we start talking with other
> developers. I think it would also be *very* helpful if you could explain the
> motivation behind these specs so we understand what problems you are trying to
> solve and what requirements you are trying to meet; you talk about this a bit
> in the conclusion, but more background would be nice.
>
> Another nit-picky comment, in the future I would suggest sending the specs
> inline in your mail; having to go to my browser to read your document and then
> cut-and-paste it into my email to comment on it means your request for
> feedback goes to the bottom of my todo list. Lower the bar for collaboration
> as much as possible, if you inline the text all we have to do is hit "reply"
> to comment on the specs.
>
> Anyway, on to your docs ...
>
> * https://people.redhat.com/sgrubb/audit/system-lifecycle.txt
>
> > System Lifecycle Auditing
> > =========================
> > This document will go over the events that are associated with starting up
> > a system and shutting it down. Knowing what events make up these actions
> > allows an analytical application to know the boundaries of all sessions and
> > actions a user may perform. It also allows identification of crashed systems
> > or malfunctioning services. The following table lists the events that make
> > up the system lifecycle in the audit trail:
> >
> > AUDIT_SYSTEM_BOOT - System boot
> > AUDIT_SYSTEM_RUNLEVEL - System runlevel change
> > AUDIT_DAEMON_START - Audit daemon startup record
> > AUDIT_DAEMON_ABORT - Audit daemon error stop record
> > AUDIT_SERVICE_START - Service (daemon) start
> > AUDIT_SERVICE_STOP - Service (daemon) stop
> > AUDIT_SYSTEM_SHUTDOWN - System shutdown
> > AUDIT_DAEMON_END - Audit daemon normal stop record
>
> Why both an AUDIT_DAEMON_ABORT and an AUDIT_DAEMON_END and not just an
> AUDIT_DAEMON_STOP with a field to indicate if it was a normal shutdown or a
> failure as outlined in the spec? This would be more consistent with the other
> daemons and the shutdown result field could potentially be reused by the init
> systems for other daemons (assuming the information was conveyed via return
> values or some other mechanism).
>
> > Lifecycle of the system
> > =======================
> > When the system is powered on, control is eventually turned over to an
> > init daemon. This daemon is responsible for starting up all other system
> > services and performing an order system shutdown when asked. This init
> > daemon should send a AUDIT_SYSTEM_BOOT event after it has done its own
> > initialization. Most init systems have different targets or modes of
> > operation that the system is turned over for interactive sessions. Examples
> > are multi-user console, multi-user graphical, etc.
>
> You mention it later, but it might be a good idea to mention in this paragraph
> that the audit daemon should be started as early as possible by the init
> daemon.
>
> > Init will determine what runlevel the system is ultimately going to try to
> > achieve. When gets there or it fails to get there, it shall issue an
> > AUDIT_SYSTEM_RUNLEVEL event to denote which mode of operation it was going
> > to be in. If an admin requests that the system switch to another runlevel,
> > then it should issue another AUDIT_SYSTEM_RUNLEVEL event.
>
> I think it would be good to have a discussion about runlevels that don't
> follow the traditional integer numbering, e.g. string based runlevels.
>
> * https://people.redhat.com/sgrubb/audit/event-enrichment
>
> > Audit Event Enrichment
> > ======================
> >
> > There are times when the audit events are stored in another machine and need
> > to be searched at a later date. Some parts of the audit event are temporally
> > limited in duration or unique to a system. This makes interpretting fields
> > that are numbers into human readable fields hard or impossible without
> > running a report at the time of the event or on the machine the event
> > occurred on.
> >
> > To address this issue, the audit daemon will get a new mode, enrich, where
> > the audit trail will be amended as follows at the time an event is logged:
> >
> > 1) Translations will be:
> > a) appended to the end of the event with the field's name in capital
> > letters
>
> Please no, let's leave field names case insensitive, perhaps an agreed upon
> suffix, e.g. "-trans"?
>
> > b) encoded if user controlled data is used for enrichment
> >
> > 2) The auparse library will:
> > a) preferentially use these fields whenever an interpretation is requested
> > b) if none exist, look up the fields on the local machine if necessary
>
> I think resolving these fields on the local machine is misleading, and
> potentially dangerous; this is especially true with respect to SELinux labels.
> If you can't resolve the field, simply display it raw and let the operator
> determine how to handle it.
>
Steve,
Can you mock up some examples of an 'enriched' event showing how it is
different from what we have now.
Being one of those people who maintain a central repository of Linux
audit, my main "ingest" concerns are to have data that is simple and,
hence, quick to parse and hence normalize.
I think the risks associated with resolution of raw data can be
mitigated by optionally maintaining the raw value as well when
transmitting the event to a central repository.
Given the above is implemented, then I would recommend the modification
of ausearch to optionally translate a complete raw enriched event into
either a single json or xml record and optionally include raw and
interpreted values. The decision to include both could be driven via
pattern matched directive (eg *id|hostname). In reality, irrespective of
whether the above is implemented or not, I would recommend (and will
probably create the patch).
To me the biggest benefit of Steve's proposal is the near real time
resolution of some values. This is particularly useful for IP addresses
(given one also notes somewhere, the name servers the system uses for
resolution) given their potential reuse in short periods of time.
Regards
Burn
^ permalink raw reply
* Weird timestamp length constraint in auparse.c
From: Santosh Ananthakrishnan @ 2015-12-10 2:10 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 882 bytes --]
Hi list
auparse breaks if supplied events with timestamps that are less than 10
characters long, including the milliseconds field. This should never happen
in production, but it can make for fairly mysterious output during testing
if you're generating your own timestamp and eventid numbers :-)
I think the issue is in the str2event function:
static int str2event(char *s, au_event_t *e)
{
char *ptr;
errno = 0;
ptr = strchr(s*+10*, ':');
if (ptr) {
e->serial = strtoul(ptr+1, NULL, 10);
This function seems to be searching for the colon that splits the timestamp
from the eventId, but it's starting at s+10, instead of just s. The
variable s points to the first byte after the "msg=audit(" prefix. (10 also
happens to be the length of that prefix, which is what made me suspicious
this might not be micro-optimization)
-Santosh
[-- Attachment #1.2: Type: text/html, Size: 1190 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: New draft standards
From: Steve Grubb @ 2015-12-10 4:35 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <1748716.onoFcfVhek@sifl>
On Tue, 08 Dec 2015 19:28:22 -0500
Paul Moore <paul@paul-moore.com> wrote:
> Okay, let's not call these "standards" and just stick with
> "specifications". The term standards has all sorts of connotations
> associated with it, both good and bad, and I think we should be clear
> when we start talking with other developers. I think it would also
> be *very* helpful if you could explain the motivation behind these
> specs so we understand what problems you are trying to solve and what
> requirements you are trying to meet; you talk about this a bit in the
> conclusion, but more background would be nice.
>
> Another nit-picky comment, in the future I would suggest sending the
> specs inline in your mail;
I think it was updated 6 times between my email and your's. :-) The
link means you review a doc that already is fixed in a number of ways
before your info.
> Anyway, on to your docs ...
>
> * https://people.redhat.com/sgrubb/audit/system-lifecycle.txt
>
> > System Lifecycle Auditing
> > =========================
> > This document will go over the events that are associated with
> > starting up a system and shutting it down. Knowing what events make
> > up these actions allows an analytical application to know the
> > boundaries of all sessions and actions a user may perform. It also
> > allows identification of crashed systems or malfunctioning
> > services. The following table lists the events that make up the
> > system lifecycle in the audit trail:
> >
> > AUDIT_SYSTEM_BOOT - System boot
> > AUDIT_SYSTEM_RUNLEVEL - System runlevel change
> > AUDIT_DAEMON_START - Audit daemon startup record
> > AUDIT_DAEMON_ABORT - Audit daemon error stop record
> > AUDIT_SERVICE_START - Service (daemon) start
> > AUDIT_SERVICE_STOP - Service (daemon) stop
> > AUDIT_SYSTEM_SHUTDOWN - System shutdown
> > AUDIT_DAEMON_END - Audit daemon normal stop record
>
> Why both an AUDIT_DAEMON_ABORT and an AUDIT_DAEMON_END and not just
> an AUDIT_DAEMON_STOP with a field to indicate if it was a normal
> shutdown or a failure as outlined in the spec?
This is documenting historical behavior that has not changed.
Originally, the event type held more weight about what was happening to
the system. I think there's a few more details for this particular
event, but that is the main reason.
> This would be more
> consistent with the other daemons and the shutdown result field could
> potentially be reused by the init systems for other daemons (assuming
> the information was conveyed via return values or some other
> mechanism).
>
> > Lifecycle of the system
> > =======================
> > When the system is powered on, control is eventually turned over to
> > an init daemon. This daemon is responsible for starting up all
> > other system services and performing an order system shutdown when
> > asked. This init daemon should send a AUDIT_SYSTEM_BOOT event after
> > it has done its own initialization. Most init systems have
> > different targets or modes of operation that the system is turned
> > over for interactive sessions. Examples are multi-user console,
> > multi-user graphical, etc.
>
> You mention it later, but it might be a good idea to mention in this
> paragraph that the audit daemon should be started as early as
> possible by the init daemon.
>
> > Init will determine what runlevel the system is ultimately going to
> > try to achieve. When gets there or it fails to get there, it shall
> > issue an AUDIT_SYSTEM_RUNLEVEL event to denote which mode of
> > operation it was going to be in. If an admin requests that the
> > system switch to another runlevel, then it should issue another
> > AUDIT_SYSTEM_RUNLEVEL event.
>
> I think it would be good to have a discussion about runlevels that
> don't follow the traditional integer numbering, e.g. string based
> runlevels.
>
> * https://people.redhat.com/sgrubb/audit/event-enrichment
>
> > Audit Event Enrichment
> > ======================
> >
> > There are times when the audit events are stored in another machine
> > and need to be searched at a later date. Some parts of the audit
> > event are temporally limited in duration or unique to a system.
> > This makes interpretting fields that are numbers into human
> > readable fields hard or impossible without running a report at the
> > time of the event or on the machine the event occurred on.
> >
> > To address this issue, the audit daemon will get a new mode,
> > enrich, where the audit trail will be amended as follows at the
> > time an event is logged:
> >
> > 1) Translations will be:
> > a) appended to the end of the event with the field's name in
> > capital letters
>
> Please no, let's leave field names case insensitive, perhaps an
> agreed upon suffix, e.g. "-trans"?
This is solving multiple issues. Grep auid would also hit auid-trans.
Also, there are a number of strstr in various bits of code. So,
changing to upper case blocks all lower case searches using case
sensitive constructs. Nowhere does the audit system consider the field
names case insensitive. On the contrary, the specifications call out
for field names to be lower case during event creation.
> > b) encoded if user controlled data is used for enrichment
> >
> > 2) The auparse library will:
> > a) preferentially use these fields whenever an interpretation is
> > requested b) if none exist, look up the fields on the local machine
> > if necessary
>
> I think resolving these fields on the local machine is misleading,
> and potentially dangerous; this is especially true with respect to
> SELinux labels. If you can't resolve the field, simply display it raw
> and let the operator determine how to handle it.
Agreed and hence the proposal. I appreciate the feedback. I'll see
about making some changes to the proposal next week.
-Steve
^ permalink raw reply
* Re: New draft standards
From: Paul Moore @ 2015-12-10 16:50 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <20151209233502.5a0efcb9@ivy-bridge>
On Wednesday, December 09, 2015 11:35:02 PM Steve Grubb wrote:
> On Tue, 08 Dec 2015 19:28:22 -0500
>
> Paul Moore <paul@paul-moore.com> wrote:
> > Okay, let's not call these "standards" and just stick with
> > "specifications". The term standards has all sorts of connotations
> > associated with it, both good and bad, and I think we should be clear
> > when we start talking with other developers. I think it would also
> > be *very* helpful if you could explain the motivation behind these
> > specs so we understand what problems you are trying to solve and what
> > requirements you are trying to meet; you talk about this a bit in the
> > conclusion, but more background would be nice.
> >
> > Another nit-picky comment, in the future I would suggest sending the
> > specs inline in your mail;
>
> I think it was updated 6 times between my email and your's. :-) The
> link means you review a doc that already is fixed in a number of ways
> before your info.
The link means it is annoying for me to review and comment. The more annoying
something is, the lower the priority I assign it. The lower priority ...
well, you get the idea. At least I hope you get the idea.
When you ask for comments from a group of people you are always going to be in
the position of having to reconcile multiple sets of feedback across multiple
revisions of a document. Hosting a plaintext document over http doesn't solve
that in any meaningful way, in some cases it actually hides changes and makes
the document history less clear.
Just use the mailing list.
> > Anyway, on to your docs ...
> >
> > * https://people.redhat.com/sgrubb/audit/system-lifecycle.txt
> >
> > > System Lifecycle Auditing
> > > =========================
> > > This document will go over the events that are associated with
> > > starting up a system and shutting it down. Knowing what events make
> > > up these actions allows an analytical application to know the
> > > boundaries of all sessions and actions a user may perform. It also
> > > allows identification of crashed systems or malfunctioning
> > > services. The following table lists the events that make up the
> > > system lifecycle in the audit trail:
> > >
> > > AUDIT_SYSTEM_BOOT - System boot
> > > AUDIT_SYSTEM_RUNLEVEL - System runlevel change
> > > AUDIT_DAEMON_START - Audit daemon startup record
> > > AUDIT_DAEMON_ABORT - Audit daemon error stop record
> > > AUDIT_SERVICE_START - Service (daemon) start
> > > AUDIT_SERVICE_STOP - Service (daemon) stop
> > > AUDIT_SYSTEM_SHUTDOWN - System shutdown
> > > AUDIT_DAEMON_END - Audit daemon normal stop record
> >
> > Why both an AUDIT_DAEMON_ABORT and an AUDIT_DAEMON_END and not just
> > an AUDIT_DAEMON_STOP with a field to indicate if it was a normal
> > shutdown or a failure as outlined in the spec?
>
> This is documenting historical behavior that has not changed.
> Originally, the event type held more weight about what was happening to
> the system. I think there's a few more details for this particular
> event, but that is the main reason.
It might be nice to add some text about what is currently done in your
document.
> > > Audit Event Enrichment
> > > ======================
> > >
> > > There are times when the audit events are stored in another machine
> > > and need to be searched at a later date. Some parts of the audit
> > > event are temporally limited in duration or unique to a system.
> > > This makes interpretting fields that are numbers into human
> > > readable fields hard or impossible without running a report at the
> > > time of the event or on the machine the event occurred on.
> > >
> > > To address this issue, the audit daemon will get a new mode,
> > > enrich, where the audit trail will be amended as follows at the
> > > time an event is logged:
> > >
> > > 1) Translations will be:
> > > a) appended to the end of the event with the field's name in
> > >
> > > capital letters
> >
> > Please no, let's leave field names case insensitive, perhaps an
> > agreed upon suffix, e.g. "-trans"?
>
> This is solving multiple issues. Grep auid would also hit auid-trans.
If you are simply greping on "auid" without any consideration of the
characters preceding or following that string you are asking for trouble. I
don't buy this as a valid reason to use uppercase for the translated fields.
> Also, there are a number of strstr in various bits of code.
The same arguments apply here.
> So, changing to upper case blocks all lower case searches using case
> sensitive constructs.
You still run into the problem that the searches you propose, e.g. 'grep
"auid"' are bad searches in the first place and moving to uppercase field
names doesn't really solve anything as 'grep "AUID"' is still problematic.
--
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