* Simple bug fix for PROCTITLE not being recognised with ausearch --debug check
From: Burn Alting @ 2015-12-18 3:20 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1: Type: text/plain, Size: 180 bytes --]
Steve,
When ausearch is given the --debug option, malformed events are written
to stderr. The PROCTITLE type record is considered to be malformed. This
patch corrects for this.
[-- Attachment #2: audit-2.4.4_debug_fix.patch --]
[-- Type: text/x-patch, Size: 455 bytes --]
diff -Npru audit-2.4.4/src/ausearch-parse.c audit-2.4.4_debug_fix/src/ausearch-parse.c
--- audit-2.4.4/src/ausearch-parse.c 2015-08-14 06:56:27.000000000 +1000
+++ audit-2.4.4_debug_fix/src/ausearch-parse.c 2015-12-18 13:52:32.103305466 +1100
@@ -162,6 +162,7 @@ int extract_search_items(llist *l)
case AUDIT_CAPSET:
case AUDIT_MMAP:
case AUDIT_NETFILTER_CFG:
+ case AUDIT_PROCTITLE:
// Nothing to parse
break;
case AUDIT_TTY:
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Use case not covered by the audit library?
From: Steve Grubb @ 2015-12-18 2:51 UTC (permalink / raw)
To: Gulland, Scott A; +Cc: Richard Guy Briggs, linux-audit@redhat.com
In-Reply-To: <20151217061003.GA12716@madcap2.tricolour.ca>
On Thursday, December 17, 2015 01:10:03 AM Richard Guy Briggs wrote:
> > No, this is an HTTP server that handles standard HTTP requests like GET,
> > POST, PUT, and DELETE. The URI specifies what resource is being acted
> > upon. These requests could come from something as simple as curl, or a
> > full blown management application, or a web GUI (which is interactive in
> > the browser). For example, you could issue a POST request to URI
> > /openswitch/v1/users to create a new user. The body of the request would
> > contain JSON or XML data indicating the user and password. There are
> > pre-determined actions/resources that can be changed. In standard REST
> > APIs, all of the URIs, their parameters and the scheme of the body are
> > documented and only these requests can be issued.>
> >
> >
> > It's based on client/server and the client may or may not be interactive
> > (e.g. a web browser). In these types of servers, we'd almost
> > exclusively be using the audit_log_user_message() API with an event type
> > of AUDIT_USYS_CONFIG. We're only logging configuration changes to the
> > switch. I think I don't understand how the "message" parameter is used
> > in this call. The man page implies a simple text message, but looking at
> > the audit.log file it appears to consist of a set of key-value
> > pairs. Is my understanding correct?>
> >
> >
> > My problem is I don't know what the proper set of "keys" are and the
> > values they should contain. If my assumptions are correct, is there any
> > documentation on on the key-value pairs and how to format the contents of
> > the message parameter? Based on what I've seen in the audit log file, I
> > would add "acct=<user>" to the contents of the message to reflect the
> > particular authenticated user who issued the REST API call.
> Well, Steve has published these as a starting point. I'm sure he'll
> chime in when he sees your message.
>
> http://people.redhat.com/sgrubb/audit/audit-events.txt
> http://people.redhat.com/sgrubb/audit/audit-parse.txt
Thanks for pointing these out, Richard.
The basic guidance for AUDIT_USYS_CONFIG is to record old and new values.
Typically old values are prefixed with 'old-' and new values are the name of
the field with no prefix.
Any field that the user could influence the value has to be handled in such a
way as to not allow them to trick the parser if they are malicious. For the
most part, we hex encode those fields and then write some code to label the
fields as encoded so that interpretation can be done later.
Since your field names may not be official names in the audit system, you may
have to filter illegal characters the user sent during event construction and
fill in spaces with an underscore or dash.
-Steve
^ permalink raw reply
* Re: Use case not covered by the audit library?
From: Richard Guy Briggs @ 2015-12-17 6:10 UTC (permalink / raw)
To: Gulland, Scott A; +Cc: linux-audit@redhat.com
In-Reply-To: <B41870ED03633F4092CDF476119204DF561CE65A@G9W0758.americas.hpqcorp.net>
On 15/12/17, Gulland, Scott A wrote:
> Hi Steve,
>
> > On Tuesday, December 15, 2015 05:13:14 AM Gulland, Scott A wrote:
> > > I have a fairly common use case that I'm not sure is covered by the audit
> > > library and I need some advice on how best to handle it. I have a daemon
> > > running as root that services REST API calls (or a web UI from a browser).
> > > An external application first establishes a session by authenticating a
> > > user which returns a token/session ID to the caller. All future REST API
> > > calls, supplies the token/session ID which allows them authenticated access
> > > to the requested resource. The token/session ID indicates what user the
> > > request is associated with. Obviously, there can be many users
> > > simultaneously issuing requests.
> > >
> > > What I need to do is specify the user on each audit log call. For example,
> > > I need to have a way to specify which user is issuing the request when I
> > > call audit_log_user_message(). Is this possible? This is a very common
> > > use case and really needs to be handled.
> >
> > Would these users be able to interact with the system in any way they
> > please?
> > If its not an interactive session, then I don't think its a _system_ event.
> > There are perfectly fine application logging frameworks to choose from. The
> > main issue is making sure that users cannot influence the records being
> > written about what they are doing.
> >
> > But if you feel that you really would like to have this in the audit trail, then
> > you can use the AUDIT_TRUSTED_APP event type and format the event any
> > way that you wish. The audit tools sort of ignore those events because
> > there's no telling what's in them.
> >
> > -Steve
>
> No, this is an HTTP server that handles standard HTTP requests like GET, POST, PUT, and DELETE. The URI specifies what resource is being acted upon. These requests could come from something as simple as curl, or a full blown management application, or a web GUI (which is interactive in the browser). For example, you could issue a POST request to URI /openswitch/v1/users to create a new user. The body of the request would contain JSON or XML data indicating the user and password. There are pre-determined actions/resources that can be changed. In standard REST APIs, all of the URIs, their parameters and the scheme of the body are documented and only these requests can be issued.
>
> It's based on client/server and the client may or may not be interactive (e.g. a web browser). In these types of servers, we'd almost exclusively be using the audit_log_user_message() API with an event type of AUDIT_USYS_CONFIG. We're only logging configuration changes to the switch. I think I don't understand how the "message" parameter is used in this call. The man page implies a simple text message, but looking at the audit.log file it appears to consist of a set of key-value pairs. Is my understanding correct?
>
> My problem is I don't know what the proper set of "keys" are and the values they should contain. If my assumptions are correct, is there any documentation on on the key-value pairs and how to format the contents of the message parameter? Based on what I've seen in the audit log file, I would add "acct=<user>" to the contents of the message to reflect the particular authenticated user who issued the REST API call.
Well, Steve has published these as a starting point. I'm sure he'll
chime in when he sees your message.
http://people.redhat.com/sgrubb/audit/audit-events.txt
http://people.redhat.com/sgrubb/audit/audit-parse.txt
> Thanks,
>
> Scott
- 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: Use case not covered by the audit library?
From: Gulland, Scott A @ 2015-12-17 4:53 UTC (permalink / raw)
To: Burn Alting, Steve Grubb, Gulland, Scott A; +Cc: linux-audit@redhat.com
In-Reply-To: <CANg1mKftPK9YuKoC5CBWt_8LZ2MkrjeW+Sb19ns10BY20CDiLA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3098 bytes --]
Hi Burn,
From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Burn Alting
Sent: Wednesday, December 16, 2015 11:56 AM
To: Steve Grubb
Cc: linux-audit@redhat.com
Subject: Re: Use case not covered by the audit library?
On 17 Dec 2015 1:24 am, "Steve Grubb" <sgrubb@redhat.com<mailto:sgrubb@redhat.com>> wrote:
>
> Hello,
>
> On Tuesday, December 15, 2015 05:13:14 AM Gulland, Scott A wrote:
> > I have a fairly common use case that I'm not sure is covered by the audit
> > library and I need some advice on how best to handle it. I have a daemon
> > running as root that services REST API calls (or a web UI from a browser).
> > An external application first establishes a session by authenticating a
> > user which returns a token/session ID to the caller. All future REST API
> > calls, supplies the token/session ID which allows them authenticated access
> > to the requested resource. The token/session ID indicates what user the
> > request is associated with. Obviously, there can be many users
> > simultaneously issuing requests.
> >
> > What I need to do is specify the user on each audit log call. For example,
> > I need to have a way to specify which user is issuing the request when I
> > call audit_log_user_message(). Is this possible? This is a very common
> > use case and really needs to be handled.
>
> Would these users be able to interact with the system in any way they please?
> If its not an interactive session, then I don't think its a _system_ event.
> There are perfectly fine application logging frameworks to choose from. The
> main issue is making sure that users cannot influence the records being written
> about what they are doing.
>
> But if you feel that you really would like to have this in the audit trail,
> then you can use the AUDIT_TRUSTED_APP event type and format the event any way
> that you wish. The audit tools sort of ignore those events because there's no
> telling what's in them.
>
> -Steve
>
Scott,
If you have to use auditd as your auditing framework, then can you
a. Test your application running on a system with a comprehensive autiting posture already deployed. That is take a CAPP configuration and add execve system call monitoring. I have found applications that extensively use auditd for application audit, slow down in such an environment.
b. If you use the auditd api then please use well formed key value pair content in your events. Follow the auditd documentation in this reguard. If not well formed, tools using auparse () and friends may discard data during the parsing.
We want to use the audit framework because after all, it is designed to track changes made to a system, and that is exactly what we want to do. We definitely want to use well formed key-value pairs, but you’ve probably seem my post to Steve. I don’t know what the “keys” I should be using or what the values for those keys should be. I’m looking for information on these key-value pairs. We need to follow the appropriate rules.
Scott
[-- Attachment #1.2: Type: text/html, Size: 6218 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* RE: Use case not covered by the audit library?
From: Gulland, Scott A @ 2015-12-17 4:21 UTC (permalink / raw)
To: Steve Grubb, linux-audit@redhat.com, Gulland, Scott A
In-Reply-To: <27894292.cgSWpRuSAQ@x2>
Hi Steve,
> On Tuesday, December 15, 2015 05:13:14 AM Gulland, Scott A wrote:
> > I have a fairly common use case that I'm not sure is covered by the audit
> > library and I need some advice on how best to handle it. I have a daemon
> > running as root that services REST API calls (or a web UI from a browser).
> > An external application first establishes a session by authenticating a
> > user which returns a token/session ID to the caller. All future REST API
> > calls, supplies the token/session ID which allows them authenticated access
> > to the requested resource. The token/session ID indicates what user the
> > request is associated with. Obviously, there can be many users
> > simultaneously issuing requests.
> >
> > What I need to do is specify the user on each audit log call. For example,
> > I need to have a way to specify which user is issuing the request when I
> > call audit_log_user_message(). Is this possible? This is a very common
> > use case and really needs to be handled.
>
> Would these users be able to interact with the system in any way they
> please?
> If its not an interactive session, then I don't think its a _system_ event.
> There are perfectly fine application logging frameworks to choose from. The
> main issue is making sure that users cannot influence the records being
> written about what they are doing.
>
> But if you feel that you really would like to have this in the audit trail, then
> you can use the AUDIT_TRUSTED_APP event type and format the event any
> way that you wish. The audit tools sort of ignore those events because
> there's no telling what's in them.
>
> -Steve
No, this is an HTTP server that handles standard HTTP requests like GET, POST, PUT, and DELETE. The URI specifies what resource is being acted upon. These requests could come from something as simple as curl, or a full blown management application, or a web GUI (which is interactive in the browser). For example, you could issue a POST request to URI /openswitch/v1/users to create a new user. The body of the request would contain JSON or XML data indicating the user and password. There are pre-determined actions/resources that can be changed. In standard REST APIs, all of the URIs, their parameters and the scheme of the body are documented and only these requests can be issued.
It's based on client/server and the client may or may not be interactive (e.g. a web browser). In these types of servers, we'd almost exclusively be using the audit_log_user_message() API with an event type of AUDIT_USYS_CONFIG. We're only logging configuration changes to the switch. I think I don't understand how the "message" parameter is used in this call. The man page implies a simple text message, but looking at the audit.log file it appears to consist of a set of key-value pairs. Is my understanding correct?
My problem is I don't know what the proper set of "keys" are and the values they should contain. If my assumptions are correct, is there any documentation on on the key-value pairs and how to format the contents of the message parameter? Based on what I've seen in the audit log file, I would add "acct=<user>" to the contents of the message to reflect the particular authenticated user who issued the REST API call.
Thanks,
Scott
^ permalink raw reply
* Re: Use case not covered by the audit library?
From: Burn Alting @ 2015-12-16 19:55 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <27894292.cgSWpRuSAQ@x2>
[-- Attachment #1.1: Type: text/plain, Size: 2324 bytes --]
On 17 Dec 2015 1:24 am, "Steve Grubb" <sgrubb@redhat.com> wrote:
>
> Hello,
>
> On Tuesday, December 15, 2015 05:13:14 AM Gulland, Scott A wrote:
> > I have a fairly common use case that I'm not sure is covered by the
audit
> > library and I need some advice on how best to handle it. I have a
daemon
> > running as root that services REST API calls (or a web UI from a
browser).
> > An external application first establishes a session by authenticating a
> > user which returns a token/session ID to the caller. All future REST
API
> > calls, supplies the token/session ID which allows them authenticated
access
> > to the requested resource. The token/session ID indicates what user
the
> > request is associated with. Obviously, there can be many users
> > simultaneously issuing requests.
> >
> > What I need to do is specify the user on each audit log call. For
example,
> > I need to have a way to specify which user is issuing the request when I
> > call audit_log_user_message(). Is this possible? This is a very
common
> > use case and really needs to be handled.
>
> Would these users be able to interact with the system in any way they
please?
> If its not an interactive session, then I don't think its a _system_
event.
> There are perfectly fine application logging frameworks to choose from.
The
> main issue is making sure that users cannot influence the records being
written
> about what they are doing.
>
> But if you feel that you really would like to have this in the audit
trail,
> then you can use the AUDIT_TRUSTED_APP event type and format the event
any way
> that you wish. The audit tools sort of ignore those events because
there's no
> telling what's in them.
>
> -Steve
>
Scott,
If you have to use auditd as your auditing framework, then can you
a. Test your application running on a system with a comprehensive autiting
posture already deployed. That is take a CAPP configuration and add execve
system call monitoring. I have found applications that extensively use
auditd for application audit, slow down in such an environment.
b. If you use the auditd api then please use well formed key value pair
content in your events. Follow the auditd documentation in this reguard. If
not well formed, tools using auparse () and friends may discard data during
the parsing.
Regard
Burn
[-- Attachment #1.2: Type: text/html, Size: 2777 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH V2 1/2] audit: stop an old auditd being starved out by a new auditd
From: Steve Grubb @ 2015-12-16 16:23 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: linux-audit, linux-kernel, pmoore, eparis, v.rathor, ctcard
In-Reply-To: <735d85abf2484b740fd3aa551cdffde67f9bd637.1450268948.git.rgb@redhat.com>
Hello Richard,
Public reply this time. :-)
On Wednesday, December 16, 2015 10:42:32 AM Richard Guy Briggs wrote:
> Nothing prevents a new auditd starting up and replacing a valid
> audit_pid when an old auditd is still running, effectively starving out
> the old auditd since audit_pid no longer points to the old valid auditd.
I guess the first question is why do we allow something to start up a new
auditd without killing off the old one? Would that be a simpler fix?
> If no message to auditd has been attempted since auditd died unnaturally
> or got killed, audit_pid will still indicate it is alive. There isn't
> an easy way to detect if an old auditd is still running on the existing
> audit_pid other than attempting to send a message to see if it fails.
> An -ECONNREFUSED almost certainly means it disappeared and can be
> replaced. Other errors are not so straightforward and may indicate
> transient problems that will resolve themselves and the old auditd will
> recover. Yet others will likely need manual intervention for which a
> new auditd will not solve the problem.
>
> Send a new message type (AUDIT_REPLACE) to the old auditd containing a
> u32 with the PID of the new auditd. If the audit replace message
> succeeds (or doesn't fail with certainty), fail to register the new
> auditd and return an error (-EEXIST).
>
> This is expected to make the patch preventing an old auditd orphaning a
> new auditd redundant.
>
> V2: Rename audit_ping to audit_replace, set seq and portid to 0 in
> the call to audit_make_reply().
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> include/uapi/linux/audit.h | 1 +
> kernel/audit.c | 16 +++++++++++++++-
> 2 files changed, 16 insertions(+), 1 deletions(-)
>
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index 843540c..cf84991 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -70,6 +70,7 @@
> #define AUDIT_TTY_SET 1017 /* Set TTY auditing status */
> #define AUDIT_SET_FEATURE 1018 /* Turn an audit feature on or off */
> #define AUDIT_GET_FEATURE 1019 /* Get which features are enabled */
> +#define AUDIT_REPLACE 1020 /* Replace auditd if this packet
unanswerd */
In every case, events in the 1000 block are to configure the kernel or to ask
the kernel a question. This is user space initiating. Kernel initiating events
are in the 1300 block of numbers.
-Steve
> #define AUDIT_FIRST_USER_MSG 1100 /* Userspace messages mostly
> uninteresting to kernel */ #define AUDIT_USER_AVC 1107 /* We filter
this
> differently */
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 36989a1..0368be2 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -809,6 +809,16 @@ static int audit_set_feature(struct sk_buff *skb)
> return 0;
> }
>
> +static int audit_replace(pid_t pid)
> +{
> + struct sk_buff *skb = audit_make_reply(0, 0, AUDIT_REPLACE, 0, 0,
> + &pid, sizeof(pid));
> +
> + if (!skb)
> + return -ENOMEM;
> + return netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
> +}
> +
> static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
> {
> u32 seq;
> @@ -870,9 +880,13 @@ static int audit_receive_msg(struct sk_buff *skb,
> struct nlmsghdr *nlh) }
> if (s.mask & AUDIT_STATUS_PID) {
> int new_pid = s.pid;
> + pid_t requesting_pid = task_tgid_vnr(current);
>
> - if ((!new_pid) && (task_tgid_vnr(current) != audit_pid))
> + if ((!new_pid) && (requesting_pid != audit_pid))
> return -EACCES;
> + if (audit_pid && new_pid &&
> + audit_replace(requesting_pid) != -ECONNREFUSED)
> + return -EEXIST;
> if (audit_enabled != AUDIT_OFF)
> audit_log_config_change("audit_pid", new_pid, audit_pid,
1);
> audit_pid = new_pid;
^ permalink raw reply
* [PATCH V2 2/2] audit: log failed attempts to change audit_pid configuration
From: Richard Guy Briggs @ 2015-12-16 15:42 UTC (permalink / raw)
To: linux-audit, linux-kernel; +Cc: v.rathor, Richard Guy Briggs
In-Reply-To: <735d85abf2484b740fd3aa551cdffde67f9bd637.1450268948.git.rgb@redhat.com>
Failed attempts to change the audit_pid configuration are not presently
logged. One case is an attempt to starve an old auditd by starting up a
new auditd when the old one is still alive and active. The other case
is an attempt to orphan a new auditd when an old auditd shuts down.
Log both as AUDIT_CONFIG_CHANGE messages with failure result.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
kernel/audit.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 0368be2..9000c6f 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -882,11 +882,15 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
int new_pid = s.pid;
pid_t requesting_pid = task_tgid_vnr(current);
- if ((!new_pid) && (requesting_pid != audit_pid))
+ if ((!new_pid) && (requesting_pid != audit_pid)) {
+ audit_log_config_change("audit_pid", new_pid, audit_pid, 0);
return -EACCES;
+ }
if (audit_pid && new_pid &&
- audit_replace(requesting_pid) != -ECONNREFUSED)
+ audit_replace(requesting_pid) != -ECONNREFUSED) {
+ audit_log_config_change("audit_pid", new_pid, audit_pid, 0);
return -EEXIST;
+ }
if (audit_enabled != AUDIT_OFF)
audit_log_config_change("audit_pid", new_pid, audit_pid, 1);
audit_pid = new_pid;
--
1.7.1
^ permalink raw reply related
* [PATCH V2 1/2] audit: stop an old auditd being starved out by a new auditd
From: Richard Guy Briggs @ 2015-12-16 15:42 UTC (permalink / raw)
To: linux-audit, linux-kernel
Cc: Richard Guy Briggs, sgrubb, pmoore, eparis, v.rathor, ctcard
Nothing prevents a new auditd starting up and replacing a valid
audit_pid when an old auditd is still running, effectively starving out
the old auditd since audit_pid no longer points to the old valid auditd.
If no message to auditd has been attempted since auditd died unnaturally
or got killed, audit_pid will still indicate it is alive. There isn't
an easy way to detect if an old auditd is still running on the existing
audit_pid other than attempting to send a message to see if it fails.
An -ECONNREFUSED almost certainly means it disappeared and can be
replaced. Other errors are not so straightforward and may indicate
transient problems that will resolve themselves and the old auditd will
recover. Yet others will likely need manual intervention for which a
new auditd will not solve the problem.
Send a new message type (AUDIT_REPLACE) to the old auditd containing a
u32 with the PID of the new auditd. If the audit replace message
succeeds (or doesn't fail with certainty), fail to register the new
auditd and return an error (-EEXIST).
This is expected to make the patch preventing an old auditd orphaning a
new auditd redundant.
V2: Rename audit_ping to audit_replace, set seq and portid to 0 in
the call to audit_make_reply().
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
include/uapi/linux/audit.h | 1 +
kernel/audit.c | 16 +++++++++++++++-
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 843540c..cf84991 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -70,6 +70,7 @@
#define AUDIT_TTY_SET 1017 /* Set TTY auditing status */
#define AUDIT_SET_FEATURE 1018 /* Turn an audit feature on or off */
#define AUDIT_GET_FEATURE 1019 /* Get which features are enabled */
+#define AUDIT_REPLACE 1020 /* Replace auditd if this packet unanswerd */
#define AUDIT_FIRST_USER_MSG 1100 /* Userspace messages mostly uninteresting to kernel */
#define AUDIT_USER_AVC 1107 /* We filter this differently */
diff --git a/kernel/audit.c b/kernel/audit.c
index 36989a1..0368be2 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -809,6 +809,16 @@ static int audit_set_feature(struct sk_buff *skb)
return 0;
}
+static int audit_replace(pid_t pid)
+{
+ struct sk_buff *skb = audit_make_reply(0, 0, AUDIT_REPLACE, 0, 0,
+ &pid, sizeof(pid));
+
+ if (!skb)
+ return -ENOMEM;
+ return netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
+}
+
static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
{
u32 seq;
@@ -870,9 +880,13 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
}
if (s.mask & AUDIT_STATUS_PID) {
int new_pid = s.pid;
+ pid_t requesting_pid = task_tgid_vnr(current);
- if ((!new_pid) && (task_tgid_vnr(current) != audit_pid))
+ if ((!new_pid) && (requesting_pid != audit_pid))
return -EACCES;
+ if (audit_pid && new_pid &&
+ audit_replace(requesting_pid) != -ECONNREFUSED)
+ return -EEXIST;
if (audit_enabled != AUDIT_OFF)
audit_log_config_change("audit_pid", new_pid, audit_pid, 1);
audit_pid = new_pid;
--
1.7.1
^ permalink raw reply related
* Re: Use case not covered by the audit library?
From: Steve Grubb @ 2015-12-16 14:22 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <B41870ED03633F4092CDF476119204DF561CDE2E@G9W0758.americas.hpqcorp.net>
Hello,
On Tuesday, December 15, 2015 05:13:14 AM Gulland, Scott A wrote:
> I have a fairly common use case that I'm not sure is covered by the audit
> library and I need some advice on how best to handle it. I have a daemon
> running as root that services REST API calls (or a web UI from a browser).
> An external application first establishes a session by authenticating a
> user which returns a token/session ID to the caller. All future REST API
> calls, supplies the token/session ID which allows them authenticated access
> to the requested resource. The token/session ID indicates what user the
> request is associated with. Obviously, there can be many users
> simultaneously issuing requests.
>
> What I need to do is specify the user on each audit log call. For example,
> I need to have a way to specify which user is issuing the request when I
> call audit_log_user_message(). Is this possible? This is a very common
> use case and really needs to be handled.
Would these users be able to interact with the system in any way they please?
If its not an interactive session, then I don't think its a _system_ event.
There are perfectly fine application logging frameworks to choose from. The
main issue is making sure that users cannot influence the records being written
about what they are doing.
But if you feel that you really would like to have this in the audit trail,
then you can use the AUDIT_TRUSTED_APP event type and format the event any way
that you wish. The audit tools sort of ignore those events because there's no
telling what's in them.
-Steve
^ permalink raw reply
* Re: New draft standards
From: Steve Grubb @ 2015-12-15 13:46 UTC (permalink / raw)
To: Burn Alting; +Cc: linux-audit
In-Reply-To: <CANg1mKc1cFDvgqW6zLoKc4qAvTnmSRE9MtMCv7LuW_cTHq192w@mail.gmail.com>
On Tuesday, December 15, 2015 09:12:54 AM Burn Alting wrote:
> I use a proprietary ELK-like system based on ausearch's -i option. I would
> like to see some variant outputs from ausearch that "packages" events into
> parse-friendly formats (json, xml) that also incorporates the local
> transformations Steve proposes. I believe this would be the most generic
> solution to support centralised log management.
>
> I am travelling now, but can write up a specification for review next week.
Yes, please do send something to the mail list for people to look at and
comment on.
If anyone wants to help influence future direction and does not want to do it
on the list, please contact me offlist and let me know how you aggregate logs.
We have to address central log aggregation and I would like to see what the
majority are using to know where effort would be best spent.
I did run across this page in my survey:
http://buildoop.github.io/
It mentions audit log processing. No idea if anyone is using this either.
-Steve
> On 15 Dec 2015 4:13 am, <Kevin.Dienst@usbank.com> wrote:
> > ELK
> > Splunk
> >
> > We use a proprietary vendor product that migrates data into an HDFS store
>
> via RabbitMQ based collectors and dumps them in raw form. From there I have
> access to all the usual "big data" tools albeit I'm not using Flume just
> yet, we're still trying to get a handle on operationalizing all the various
> big data component so that data science developers can focus on development
> instead of operations and support of the hardware/software ecosystem.
^ permalink raw reply
* Use case not covered by the audit library?
From: Gulland, Scott A @ 2015-12-15 5:13 UTC (permalink / raw)
To: linux-audit@redhat.com, Gulland, Scott A
Hi,
I have a fairly common use case that I'm not sure is covered by the audit library and I need some advice on how best to handle it. I have a daemon running as root that services REST API calls (or a web UI from a browser). An external application first establishes a session by authenticating a user which returns a token/session ID to the caller. All future REST API calls, supplies the token/session ID which allows them authenticated access to the requested resource. The token/session ID indicates what user the request is associated with. Obviously, there can be many users simultaneously issuing requests.
What I need to do is specify the user on each audit log call. For example, I need to have a way to specify which user is issuing the request when I call audit_log_user_message(). Is this possible? This is a very common use case and really needs to be handled.
Scott Gulland
916.785.1497
HPE Networking, CEB R&D
8000 Foothills Blvd; MS - 5505
Roseville, CA 95747
USA
^ permalink raw reply
* Re: New draft standards
From: Richard Guy Briggs @ 2015-12-15 5:11 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <CAHC9VhSW4=yVaRxRj=VvDmm1YOq_QgXxYB9H=fZHTOa8Y8THow@mail.gmail.com>
On 15/12/10, Paul Moore wrote:
> On Thu, Dec 10, 2015 at 5:49 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Wed, 09 Dec 2015 12:43:37 +1100
> > Burn Alting <burn@swtf.dyndns.org> wrote:
> >
> >> Steve,
> >>
> >> Can you mock up some examples of an 'enriched' event showing how it is
> >> different from what we have now.
> >
> > type=LOGIN msg=audit(1449782897.896:2496): pid=1768 uid=0
> > subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 old-auid=4294967295
> > auid=4325 old-ses=4294967295 ses=1 res=1 UID="root" OLD-AUID="unset"
> > AUID="sgrubb"
> >
> > type=SYSCALL msg=audit(1449778741.412:4952): arch=c000003e syscall=40
> > success=no exit=-22 a0=3 a1=0 a2=0 a3=4000 items=0 ppid=7362 pid=7994
> > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> > tty=(none) ses=4294967295 comm="systemd-coredum"
> > exe="/usr/lib/systemd/systemd-coredump"
> > subj=system_u:system_r:init_t:s0 key="einval-retcode" ARCH=x86_64
> > SYSCALL=sendfile AUID="unset" UID="root" GID="root" EUID="root"
> > SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
>
> This could be confusing on a system with "unset" as a user.
As we do with "none", "(unset)" might be better?
> paul moore
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* Re: New draft standards
From: Burn Alting @ 2015-12-14 22:12 UTC (permalink / raw)
To: Kevin.Dienst; +Cc: linux-audit@redhat.com
In-Reply-To: <201512141711.tBEHBAAc004559@int-mx13.intmail.prod.int.phx2.redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 2339 bytes --]
I use a proprietary ELK-like system based on ausearch's -i option. I would
like to see some variant outputs from ausearch that "packages" events into
parse-friendly formats (json, xml) that also incorporates the local
transformations Steve proposes. I believe this would be the most generic
solution to support centralised log management.
I am travelling now, but can write up a specification for review next week.
Burn Alting
On 15 Dec 2015 4:13 am, <Kevin.Dienst@usbank.com> wrote:
>
> ELK
> Splunk
>
> We use a proprietary vendor product that migrates data into an HDFS store
via RabbitMQ based collectors and dumps them in raw form. From there I have
access to all the usual "big data" tools albeit I'm not using Flume just
yet, we're still trying to get a handle on operationalizing all the various
big data component so that data science developers can focus on development
instead of operations and support of the hardware/software ecosystem.
>
> Kevin D Dienst
>
>
>
>
> From: Joe Wulf <joe_wulf@yahoo.com>
> To: "linux-audit@redhat.com" <linux-audit@redhat.com>
> Date: 12/14/2015 10:51 AM
> Subject: Re: New draft standards
> Sent by: linux-audit-bounces@redhat.com
> ________________________________
>
>
>
> Steve,
>
> The last place I was at heavily used Splunk and then transitioned to
dual-routing a substantial portion of the logs from across the
infrastructure to ELK, as well.
>
> -Joe
>
> ________________________________
> From: Steve Grubb <sgrubb@redhat.com>
> To: F Rafi <farhanible@gmail.com>; "linux-audit@redhat.com" <
linux-audit@redhat.com>
> Sent: Monday, December 14, 2015 10:34 AM
> Subject: Re: New draft standards
>
> But I guess this gives me an opportunity to ask the community what tools
they
> are using for audit log collection and viewing? Its been a couple years
since
> e had this discussion on the mail list and I think some things have
changed.
>
> Do people use ELK?
> Apache Flume?
> Something else?
>
> It might be possible to write a plugin to translate the audit logs into
the
> native format of these tools.
>
>
>
> -Steve
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
[-- Attachment #1.2: Type: text/html, Size: 3622 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Weird timestamp length constraint in auparse.c
From: Santosh Ananthakrishnan @ 2015-12-14 21:24 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <3542651.21VHabrmFL@x2>
[-- Attachment #1.1: Type: text/plain, Size: 273 bytes --]
I don't think anything needs to be done, a malformed timestamp only causes
that line to be parsed badly. I was wondering if this behavior was
intentional, now that I see it was, I'm happy to leave this as an FYI for
anybody else being lazy with their test case generation.
[-- Attachment #1.2: Type: text/html, Size: 406 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Weird timestamp length constraint in auparse.c
From: Steve Grubb @ 2015-12-14 21:02 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CAKC2Jd6sbeHdMBC_TT314NZ1TFe6QMtShXp=dQLCPb3KPiYCNA@mail.gmail.com>
Hello,
On Wednesday, December 09, 2015 06:10:08 PM Santosh Ananthakrishnan wrote:
> 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);
Yes, this is intentional. Let's look at an event:
type=DAEMON_START msg=audit(1450095206.768:6444):
When str2event is entered, the pointer is at the '1'. The function calling it
located the parenthesis.
> 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)
It also turns out to be the length of the decimal number for time. The reason
that we can "safely" do this is because the audit project started in 2004.
There would not be any kernel prior to that which has audit events created by
the current audit system. If you get the time_t representation for August
2004, which is the time that the Linux audit mail list was started, you get:
1091332800. Any time after that would be bigger and longer. When time_t maxes
out it'll look like:
time_t: 0xFFFFFFFF, dec: 4294967295, date: Sun Feb 7 01:28:15 2106
Its still 10 digits long. So, the idea was to skip over the first 10 characters
and start looking for the serial number closer to where its going to be in the
buffer.
I suppose a quick check could be done to make sure we don't have malformed
records. Is that what you were wanting to see done?
Thanks,
-Steve
^ permalink raw reply
* Re: New draft standards
From: Kevin.Dienst @ 2015-12-14 17:01 UTC (permalink / raw)
To: Joe Wulf; +Cc: linux-audit@redhat.com
In-Reply-To: <1459913744.767260.1450111103969.JavaMail.yahoo@mail.yahoo.com>
[-- Attachment #1.1: Type: text/plain, Size: 1591 bytes --]
ELK
Splunk
We use a proprietary vendor product that migrates data into an HDFS store
via RabbitMQ based collectors and dumps them in raw form. From there I
have access to all the usual "big data" tools albeit I'm not using Flume
just yet, we're still trying to get a handle on operationalizing all the
various big data component so that data science developers can focus on
development instead of operations and support of the hardware/software
ecosystem.
Kevin D Dienst
From: Joe Wulf <joe_wulf@yahoo.com>
To: "linux-audit@redhat.com" <linux-audit@redhat.com>
Date: 12/14/2015 10:51 AM
Subject: Re: New draft standards
Sent by: linux-audit-bounces@redhat.com
Steve,
The last place I was at heavily used Splunk and then transitioned to
dual-routing a substantial portion of the logs from across the
infrastructure to ELK, as well.
-Joe
From: Steve Grubb <sgrubb@redhat.com>
To: F Rafi <farhanible@gmail.com>; "linux-audit@redhat.com"
<linux-audit@redhat.com>
Sent: Monday, December 14, 2015 10:34 AM
Subject: Re: New draft standards
But I guess this gives me an opportunity to ask the community what tools
they
are using for audit log collection and viewing? Its been a couple years
since
e had this discussion on the mail list and I think some things have
changed.
Do people use ELK?
Apache Flume?
Something else?
It might be possible to write a plugin to translate the audit logs into
the
native format of these tools.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
[-- Attachment #1.2: Type: text/html, Size: 3118 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: New draft standards
From: Joe Wulf @ 2015-12-14 16:38 UTC (permalink / raw)
To: linux-audit@redhat.com
In-Reply-To: <1736195.o09BuzvBta@x2>
[-- Attachment #1.1: Type: text/plain, Size: 795 bytes --]
Steve,
The last place I was at heavily used Splunk and then transitioned to dual-routing a substantial portion of the logs from across the infrastructure to ELK, as well.
-Joe
From: Steve Grubb <sgrubb@redhat.com>
To: F Rafi <farhanible@gmail.com>; "linux-audit@redhat.com" <linux-audit@redhat.com>
Sent: Monday, December 14, 2015 10:34 AM
Subject: Re: New draft standards
But I guess this gives me an opportunity to ask the community what tools they
are using for audit log collection and viewing? Its been a couple years since
e had this discussion on the mail list and I think some things have changed.
Do people use ELK?
Apache Flume?
Something else?
It might be possible to write a plugin to translate the audit logs into the
native format of these tools.
-Steve
[-- Attachment #1.2: Type: text/html, Size: 2813 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: New draft standards
From: Steve Grubb @ 2015-12-14 15:34 UTC (permalink / raw)
To: F Rafi, linux-audit@redhat.com
In-Reply-To: <CABXp1ctED+jd0oadRph8WebgF7b3UumsC9nELo2syqxny4n_YA@mail.gmail.com>
On Thursday, December 10, 2015 12:40:55 PM F Rafi wrote:
> My comments are more from a log user (not developer) perspective. We are
> exporting close to 10GB/day of mostly auditd logs. This will potentially go
> upto 20GB/day next year.
>
> I'd prefer the ability to translate all auditd logs before they are written
> to disk. I believe this is what you have proposed, just wanted to confirm.
That is not exactly what I proposed. What I was proposing was to record the
translation of things that could change between systems and thus prevent
correct interpretation later. Doing all translations is technically possible
but would slow down auditd just a bit and increase the amount of data on disk.
But doing this is not really necessary for the native audit tools.
But I guess this gives me an opportunity to ask the community what tools they
are using for audit log collection and viewing? Its been a couple years since
e had this discussion on the mail list and I think some things have changed.
Do people use ELK?
Apache Flume?
Something else?
It might be possible to write a plugin to translate the audit logs into the
native format of these tools.
> This means that uid / gid / auid will resolve on the same machine that the
> logs were generated on.
>
> You mentioned IP translation in the enrichment doc. I'm currently tackling
> this for automated analysis of these logs (syscall 42). Currently the IPs
> are written in hex. It would be nice to have this translated into the IPv4
> decimal octets before the logs are written (I haven't checked what is
> written for IPv6).
>
> One thing I'm having a very hard time reconciling are the multiple lines
> per log event.
In a way, that can't be avoided. I am working on a new representation of the
audit stream that would be just one line in the "cooked" mode.
-Steve
^ permalink raw reply
* SELinux/audit kernel repo process changes
From: Paul Moore @ 2015-12-13 23:06 UTC (permalink / raw)
To: selinux, linux-audit; +Cc: linux-security-module
In an effort to make it a bit easier to maintain the kernel-secnext COPR I'm
making some slight changes to how I manage the SELinux and audit kernel
repositories. The downside is that there is now going to be a regular rebase
as part of the release cycle, but at least it will be well defined and part of
the process, unlike the current reactionary rebases.
Starting with the next merge window, I'll be following the process below:
1. When a new kernel is released, rebase the repository's upstream branch to
the tagged kernel release (or the latest LSM upstream branch in the case of
SELinux) and apply the next branch on top of the upstream branch. Send a pull
request for the upstream branch to the next level maintainer.
2. Create a new branch, stable-X.XX, a copy of the upstream branch that was
sent during the merge window.
3. Reset the next branch to the upstream branch that was sent during the merge
window. At this point the upstream, next, and latest stable-X.XX branch
should be identical.
4. Accept patches into both the stable-X.XX and next branches; as necessary,
send pull requests for stable-X.XX to the next level maintainer. Continue
until the next kernel is released and the process repeats.
As in the past, this process is subject to change, but I'm hopeful that this
approach should work for the foreseeable future.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: New draft standards
From: Paul Moore @ 2015-12-10 22:59 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <20151210174929.3883529b@ivy-bridge>
On Thu, Dec 10, 2015 at 5:49 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wed, 09 Dec 2015 12:43:37 +1100
> Burn Alting <burn@swtf.dyndns.org> wrote:
>
>> Steve,
>>
>> Can you mock up some examples of an 'enriched' event showing how it is
>> different from what we have now.
>
> type=LOGIN msg=audit(1449782897.896:2496): pid=1768 uid=0
> subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 old-auid=4294967295
> auid=4325 old-ses=4294967295 ses=1 res=1 UID="root" OLD-AUID="unset"
> AUID="sgrubb"
>
> type=SYSCALL msg=audit(1449778741.412:4952): arch=c000003e syscall=40
> success=no exit=-22 a0=3 a1=0 a2=0 a3=4000 items=0 ppid=7362 pid=7994
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="systemd-coredum"
> exe="/usr/lib/systemd/systemd-coredump"
> subj=system_u:system_r:init_t:s0 key="einval-retcode" ARCH=x86_64
> SYSCALL=sendfile AUID="unset" UID="root" GID="root" EUID="root"
> SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
This could be confusing on a system with "unset" as a user.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: New draft standards
From: Steve Grubb @ 2015-12-10 22:49 UTC (permalink / raw)
To: Burn Alting; +Cc: linux-audit
In-Reply-To: <1449625417.8064.61.camel@swtf.swtf.dyndns.org>
On Wed, 09 Dec 2015 12:43:37 +1100
Burn Alting <burn@swtf.dyndns.org> wrote:
> 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.
type=LOGIN msg=audit(1449782897.896:2496): pid=1768 uid=0
subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 old-auid=4294967295
auid=4325 old-ses=4294967295 ses=1 res=1 UID="root" OLD-AUID="unset"
AUID="sgrubb"
type=SYSCALL msg=audit(1449778741.412:4952): arch=c000003e syscall=40
success=no exit=-22 a0=3 a1=0 a2=0 a3=4000 items=0 ppid=7362 pid=7994
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="systemd-coredum"
exe="/usr/lib/systemd/systemd-coredump"
subj=system_u:system_r:init_t:s0 key="einval-retcode" ARCH=x86_64
SYSCALL=sendfile AUID="unset" UID="root" GID="root" EUID="root"
SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
-Steve
> 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.
^ permalink raw reply
* Re: Wrong audit message type when policy is reloaded
From: Laurent Bigonville @ 2015-12-10 17:53 UTC (permalink / raw)
To: linux-audit; +Cc: selinux
In-Reply-To: <563CD57E.8090004@tycho.nsa.gov>
I guess I should have CCed the linux-audit mailing list from the start.
As said in my initial mail (see bellow) wheb SELinux user object manager
are reloading the policy, an audit message with a wrong type is logged
USER_AVC vs USER_MAC_POLICY_LOAD.
Le 06/11/15 17:29, Stephen Smalley a écrit :
> On 11/06/2015 11:10 AM, Laurent Bigonville wrote:
>> Hi,
>>
>> When the policy is reloaded, systemd and dbus are sending a USER_AVC
>> audit event instead of a USER_MAC_POLICY_LOAD one.
>>
>> Looking at an other object manager (the xserver) it uses the following
>> code:
>> http://cgit.freedesktop.org/xorg/xserver/tree/Xext/xselinux_hooks.c#n300
>>
>> Can we really link SELINUX_INFO to AUDIT_USER_MAC_POLICY_LOAD? Is there
>> a better way to achieve this?
>>
>> An downstream bug has been opened:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1195330
>
> I think when they introduced the audit support, they should have added
> a new type value in libselinux for MAC_POLICY_LOAD, and then they
> could have handled this cleanly in their callback functions. That is
> what I would do. I guess now we have to figure out how to do so
> compatibly...
>
>
^ permalink raw reply
* Re: New draft standards
From: F Rafi @ 2015-12-10 17:40 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <20151209233502.5a0efcb9@ivy-bridge>
[-- Attachment #1.1: Type: text/plain, Size: 7069 bytes --]
My comments are more from a log user (not developer) perspective. We are
exporting close to 10GB/day of mostly auditd logs. This will potentially go
upto 20GB/day next year.
I'd prefer the ability to translate all auditd logs before they are written
to disk. I believe this is what you have proposed, just wanted to confirm.
This means that uid / gid / auid will resolve on the same machine that the
logs were generated on.
You mentioned IP translation in the enrichment doc. I'm currently tackling
this for automated analysis of these logs (syscall 42). Currently the IPs
are written in hex. It would be nice to have this translated into the IPv4
decimal octets before the logs are written (I haven't checked what is
written for IPv6).
One thing I'm having a very hard time reconciling are the multiple lines
per log event.
Thanks,
-Farhan
On Wed, Dec 9, 2015 at 11:35 PM, Steve Grubb <sgrubb@redhat.com> 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.
>
>
> > 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
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
[-- Attachment #1.2: Type: text/html, Size: 9083 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ 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