* Re: New draft standards
From: Burn Alting @ 2015-12-28 7:24 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <2221771.1qUNZOCjO5@x2>
On Sun, 2015-12-27 at 10:06 -0500, Steve Grubb wrote:
> On Sunday, December 27, 2015 11:30:59 AM Burn Alting wrote:
> > I'll start with the statement I am happy to enhance the audit capability
> > of Linux in any way (read that as a direct offer to help).
>
> Thanks!
>
> > > I'm somewhat interested in this. I'm just not sure where the best place to
> > > do all this is. Should it be in ausearch? Should it be in auditd? Should
> > > it be in the remote logging plugin? Should audit utilities be modified to
> > > accept this new form of input?
> >
> > I've concentrated on ausearch as this is the only tool that
> > comprehensively parses all existing audit records, both well formed and
> > incorrectly formed. As you know auparse() has difficulties with
> > mal-formed events.
>
> Its main problem is dealing with interlaced records. The kernel does not
> serialize the audit stream. Whatever thread/process is executing at the moment
> can trigger a multi-part or single line event. For example:
>
> type=SYSCALL msg=audit(1396522853.933:313): arch=c000003e syscall=313
> success=yes exit=0 a0=0 a1=41a396 a2=0 a3=0 items=1348 ppid=1263 pid=1264
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> ses=4294967295 tty=(none) comm="modprobe" exe="/usr/bin/kmod"
> subj=system_u:system_r:insmod_t:s0 key="module-load"
> type=LOGIN msg=audit(1396522854.227:460): pid=1523 uid=0 old auid=4294967295
> new auid=4325 old ses=4294967295 new ses=1 res=1
> type=PATH msg=audit(1396522853.933:313): item=0 name=(null) inode=165
> dev=00:06 mode=040755 ouid=0 ogid=0 rdev=00:00
> obj=system_u:object_r:debugfs_t:s0 nametype=PARENT
> type=PATH msg=audit(1396522853.933:313): item=1 name=(null) inode=11206
> dev=00:06 mode=040755 ouid=0 ogid=0 rdev=00:00
> obj=system_u:object_r:debugfs_t:s0 nametype=CREATE
> type=LOGIN msg=audit(1396522854.315:461): pid=1518 uid=0 old auid=4294967295
> new auid=4325 old ses=4294967295 new ses=1 res=1
> type=PATH msg=audit(1396522853.933:313): item=2 name=(null) inode=11206
> dev=00:06 mode=040755 ouid=0 ogid=0 rdev=00:00
> obj=system_u:object_r:debugfs_t:s0 nametype=PARENT
>
> That should be 3 events.
>
I wasn't too concerned about the interleaved events but the incorrect
use of the audit message as per
type=USER_CHAUTHTOK msg=audit(12/28/2015 18:00:30.858:17862432) :
pid=13418 uid=root auid=burn ses=1
subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 msg='op=change
password id=burn exe=/usr/bin/passwd hostname=? addr=? terminal=pts/0
res=success'
where auparse with discard the string 'password' changing
op=change password id=burn exe=/usr/bin/passwd
to
op=change id=burn exe=/usr/bin/passwd
>
> > Ausearch also has the benefit of not effecting real time performance - I'd not
> > like auditd have to wait on an external DNS service to timeout when
> > attempting to resolve an 'addr' field.
>
> Yeah, I'm thinking about just breaking down the SOCKADDR record into src/dst
> ip and src/dst port and then leaving it as that for now.
>
>
> > Whatever is done, the code needs to be modular so that any utility, be
> > it ausearch, auditd or an audispd plugin, or an independent auparse()
> > based utility can make use of it.
> >
> > Perhaps to address the higher level audit needs, we can provide an
> > additional output format to my proposed changes for 'interpretive
> > formatting' to be that of 'descriptive statements'. This would be
> > similar to Windows auditing when it allows one to include 'Display
> > Information' field which provides a 'human readable' description of the
> > event data.
>
> I'm not familiar with Windows auditing, but yeah.
>
> > Perhaps the thrust should be
> > a. address performance
>
> I might have this solved. I'll send a separate email.
>
> > b. ensure auparse() can better deal with mal-formed events
>
> This would be a big contribution to the project.
>
> > c. provide interpretative formatting
>
> Yes. I think this a good order that has the right things in the right
> priority. There is one other issue that I need to tackle at some point. The
> auparse library does a lot of string manipulation. As such it winds up doing a
> lot of strtok/malloc/free. I'd like to see this run faster somehow. Perhaps
> moving to ustr could help. Or maybe having a list of pointers/lengths to avoid
> malloc/free. But auparse needs a performance boost, too.
>
> -Steve
^ permalink raw reply
* auditd performance
From: Steve Grubb @ 2015-12-27 15:30 UTC (permalink / raw)
To: linux-audit
Hello,
I've been looking into auditd's performance. The first thing I did was to
measure the rate at which it could log things with various settings. To do
this test, I had 2 windows open. One to start auditd from the command line
without systemd interference and one to run a script as follows:
auditctl -D
auditctl -b 16440
auditctl -f 0
auditctl --backlog_wait_time 100
auditctl -a always,exit -F arch=x86_64 -S all
sleep 3
service auditd stop
auditctl -D
The results of various settings are as follows:
FLUSH FREQ Events/sec
------------------------------------------------------
SYNC 45
DATA 105
INCREMENTAL 20 400
50 1000
100 1815
200 3080
400 5800
1000 10100
2000 15275
4000 18650
8000 24075
NONE 38300
In looking further, I found that there was a lot of lock contention and
scheduling issues because of pthreads. I mapped out the paths in the code to
get a picture of where events come from and where they go:
http://people.readhat.com/sgrubb/audit/auditd-data-flow.pdf
The blue boxes are where events come from, the red boxes are where we have
contention. The gray is the path on the logging thread. The white boxes are
the main thread.
What I found is that if I make enqueue_event call write_to_log directly, it
doubles the throughput of the audit daemon. IOW, going from multi-threaded to
singly threaded makes a huge difference. The audit daemon was multi-threaded
from the very first public release back in 2004 before I started working on it.
So, what I think I am going to do is fix it to be singly threaded, fix the
signal handlers to set a variable on error so that the main thread picks it up
to serialize it with other events, move size check and rotate code, and remove
the pthreads code.
That leaves an issue with dispatching events to other programs. What I have
been thinking about is perhaps using libevfibers to manage switching between
logging and dispatching.
One other tidbit that I found out during testing, if I generate so many events
that it overflows the kernel queue, the default settings for backlog_wait_time
makes the system unusable. It acts like its live-locked. So, I would recommend
that the default setting in the kernel be changed to something more livable
and anyone concerned about this to explicitly set the value to something low.
-Steve
^ permalink raw reply
* Re: New draft standards
From: Steve Grubb @ 2015-12-27 15:06 UTC (permalink / raw)
To: burn; +Cc: linux-audit
In-Reply-To: <1451176259.3232.99.camel@swtf.swtf.dyndns.org>
On Sunday, December 27, 2015 11:30:59 AM Burn Alting wrote:
> I'll start with the statement I am happy to enhance the audit capability
> of Linux in any way (read that as a direct offer to help).
Thanks!
> > I'm somewhat interested in this. I'm just not sure where the best place to
> > do all this is. Should it be in ausearch? Should it be in auditd? Should
> > it be in the remote logging plugin? Should audit utilities be modified to
> > accept this new form of input?
>
> I've concentrated on ausearch as this is the only tool that
> comprehensively parses all existing audit records, both well formed and
> incorrectly formed. As you know auparse() has difficulties with
> mal-formed events.
Its main problem is dealing with interlaced records. The kernel does not
serialize the audit stream. Whatever thread/process is executing at the moment
can trigger a multi-part or single line event. For example:
type=SYSCALL msg=audit(1396522853.933:313): arch=c000003e syscall=313
success=yes exit=0 a0=0 a1=41a396 a2=0 a3=0 items=1348 ppid=1263 pid=1264
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
ses=4294967295 tty=(none) comm="modprobe" exe="/usr/bin/kmod"
subj=system_u:system_r:insmod_t:s0 key="module-load"
type=LOGIN msg=audit(1396522854.227:460): pid=1523 uid=0 old auid=4294967295
new auid=4325 old ses=4294967295 new ses=1 res=1
type=PATH msg=audit(1396522853.933:313): item=0 name=(null) inode=165
dev=00:06 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:debugfs_t:s0 nametype=PARENT
type=PATH msg=audit(1396522853.933:313): item=1 name=(null) inode=11206
dev=00:06 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:debugfs_t:s0 nametype=CREATE
type=LOGIN msg=audit(1396522854.315:461): pid=1518 uid=0 old auid=4294967295
new auid=4325 old ses=4294967295 new ses=1 res=1
type=PATH msg=audit(1396522853.933:313): item=2 name=(null) inode=11206
dev=00:06 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:debugfs_t:s0 nametype=PARENT
That should be 3 events.
> Ausearch also has the benefit of not effecting real time performance - I'd not
> like auditd have to wait on an external DNS service to timeout when
> attempting to resolve an 'addr' field.
Yeah, I'm thinking about just breaking down the SOCKADDR record into src/dst
ip and src/dst port and then leaving it as that for now.
> Whatever is done, the code needs to be modular so that any utility, be
> it ausearch, auditd or an audispd plugin, or an independent auparse()
> based utility can make use of it.
>
> Perhaps to address the higher level audit needs, we can provide an
> additional output format to my proposed changes for 'interpretive
> formatting' to be that of 'descriptive statements'. This would be
> similar to Windows auditing when it allows one to include 'Display
> Information' field which provides a 'human readable' description of the
> event data.
I'm not familiar with Windows auditing, but yeah.
> Perhaps the thrust should be
> a. address performance
I might have this solved. I'll send a separate email.
> b. ensure auparse() can better deal with mal-formed events
This would be a big contribution to the project.
> c. provide interpretative formatting
Yes. I think this a good order that has the right things in the right
priority. There is one other issue that I need to tackle at some point. The
auparse library does a lot of string manipulation. As such it winds up doing a
lot of strtok/malloc/free. I'd like to see this run faster somehow. Perhaps
moving to ustr could help. Or maybe having a list of pointers/lengths to avoid
malloc/free. But auparse needs a performance boost, too.
-Steve
^ permalink raw reply
* Re: New draft standards
From: Burn Alting @ 2015-12-27 0:30 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <7685993.nLr6Gj3DPT@x2>
On Sat, 2015-12-26 at 11:38 -0500, Steve Grubb wrote:
> On Thursday, December 24, 2015 09:44:00 AM Burn Alting wrote:
> > On Fri, 2015-12-18 at 16:12 +1100, Burn Alting wrote:
> > > On Tue, 2015-12-15 at 08:46 -0500, Steve Grubb wrote:
> > > > 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.
> > >
> > > All,
> > >
> > > To reiterate, my need is to generate easy to parse events over which
> > > local interpretation has been applied, retaining raw input to the some
> > > of the interpretations if required. I want to then transmit the complete
> > > interpreted event to my central event repository.
> > >
> > > My proposal is that ausearch gains the following 'interpreted output'
> > > options
> > >
> > > --Xo plain|json|xml
> > > generate plain (cf --interpret), xml or json formatted events
> > >
> > > --Xr key_a'+'key_b'+'key_c
> > > include raw value for given keys using the the new key
> > > __r_key_a, __r_key_b, etc. The special key __all__ is
> > > interpreted to retain the complete raw record. If the raw value
> > > has no interpreted value, then we will end up with two keys with
> > > the same value.
> > >
> > > I have attached the XSD from which the XML and JSON formats could be
> > > defined.
> >
> > Is there any interest in this? If is was available, would people make
> > use of it?
Steve,
I'll start with the statement I am happy to enhance the audit capability
of Linux in any way (read that as a direct offer to help).
> I'm somewhat interested in this. I'm just not sure where the best place to do
> all this is. Should it be in ausearch? Should it be in auditd? Should it be in
> the remote logging plugin? Should audit utilities be modified to accept this
> new form of input?
I've concentrated on ausearch as this is the only tool that
comprehensively parses all existing audit records, both well formed and
incorrectly formed. As you know auparse() has difficulties with
mal-formed events. Ausearch also has the benefit of not effecting real
time performance - I'd not like auditd have to wait on an external DNS
service to timeout when attempting to resolve an 'addr' field.
Whatever is done, the code needs to be modular so that any utility, be
it ausearch, auditd or an audispd plugin, or an independent auparse()
based utility can make use of it.
Perhaps to address the higher level audit needs, we can provide an
additional output format to my proposed changes for 'interpretive
formatting' to be that of 'descriptive statements'. This would be
similar to Windows auditing when it allows one to include 'Display
Information' field which provides a 'human readable' description of the
event data.
Perhaps the thrust should be
a. address performance
b. ensure auparse() can better deal with mal-formed events
c. provide interpretative formatting
Regards
Burn
> Ultimately, I am wanting to be able to reduce the audit records down to
> English sentences something like this:
>
> On 1-node at 2-time 3-subj 4-acting-as 5-results 6-action 7-what 8-using
>
> Which maps to
> 1) node
> 2) time
> 3) auid, failed logins=remote system
> 4) uid (only when uid != auid) or role (when not unconfined_t)
> 5) res - successfully / failed to
> 6) op, syscall, type, key - requires per type classification
> 7) path,system
> 8) exe,comm
>
> So, what I was thinking about is looking at the whole event and picking out
> the node, time, subject, object, action, and results. The subject and object
> would be further broken down to primary identity, secondary identity, and
> attributes. I was planning to put this into an extension of auparse so that
> events could be dumped out using the classification system.
>
> My thoughts had been to organize the event data to support something along
> these lines. I want to get the events easier to understand.
>
>
> > If so I can modify ausearch and generate a proposed patch over the
> > Christmas break.
>
> At the moment, I'm looking at auditd performance improvements to prepare for
> the enrichment of audit records. You're one step ahead of where I am. I hope
> to finish this performance work soon so that I can start thinking about the
> problem you are. :-)
>
> Of course...we could look at the auditd performance issues together and then
> move on to event formatting.
^ permalink raw reply
* Re: New draft standards
From: Steve Grubb @ 2015-12-26 16:38 UTC (permalink / raw)
To: linux-audit, burn
In-Reply-To: <1450910640.3232.18.camel@swtf.swtf.dyndns.org>
On Thursday, December 24, 2015 09:44:00 AM Burn Alting wrote:
> On Fri, 2015-12-18 at 16:12 +1100, Burn Alting wrote:
> > On Tue, 2015-12-15 at 08:46 -0500, Steve Grubb wrote:
> > > 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.
> >
> > All,
> >
> > To reiterate, my need is to generate easy to parse events over which
> > local interpretation has been applied, retaining raw input to the some
> > of the interpretations if required. I want to then transmit the complete
> > interpreted event to my central event repository.
> >
> > My proposal is that ausearch gains the following 'interpreted output'
> > options
> >
> > --Xo plain|json|xml
> > generate plain (cf --interpret), xml or json formatted events
> >
> > --Xr key_a'+'key_b'+'key_c
> > include raw value for given keys using the the new key
> > __r_key_a, __r_key_b, etc. The special key __all__ is
> > interpreted to retain the complete raw record. If the raw value
> > has no interpreted value, then we will end up with two keys with
> > the same value.
> >
> > I have attached the XSD from which the XML and JSON formats could be
> > defined.
>
> Is there any interest in this? If is was available, would people make
> use of it?
I'm somewhat interested in this. I'm just not sure where the best place to do
all this is. Should it be in ausearch? Should it be in auditd? Should it be in
the remote logging plugin? Should audit utilities be modified to accept this
new form of input?
Ultimately, I am wanting to be able to reduce the audit records down to
English sentences something like this:
On 1-node at 2-time 3-subj 4-acting-as 5-results 6-action 7-what 8-using
Which maps to
1) node
2) time
3) auid, failed logins=remote system
4) uid (only when uid != auid) or role (when not unconfined_t)
5) res - successfully / failed to
6) op, syscall, type, key - requires per type classification
7) path,system
8) exe,comm
So, what I was thinking about is looking at the whole event and picking out
the node, time, subject, object, action, and results. The subject and object
would be further broken down to primary identity, secondary identity, and
attributes. I was planning to put this into an extension of auparse so that
events could be dumped out using the classification system.
My thoughts had been to organize the event data to support something along
these lines. I want to get the events easier to understand.
> If so I can modify ausearch and generate a proposed patch over the
> Christmas break.
At the moment, I'm looking at auditd performance improvements to prepare for
the enrichment of audit records. You're one step ahead of where I am. I hope
to finish this performance work soon so that I can start thinking about the
problem you are. :-)
Of course...we could look at the auditd performance issues together and then
move on to event formatting.
-Steve
^ permalink raw reply
* Re: New draft standards
From: Burn Alting @ 2015-12-23 22:44 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1450415528.14944.28.camel@swtf.swtf.dyndns.org>
On Fri, 2015-12-18 at 16:12 +1100, Burn Alting wrote:
> On Tue, 2015-12-15 at 08:46 -0500, Steve Grubb wrote:
> > 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.
> >
> All,
>
> To reiterate, my need is to generate easy to parse events over which
> local interpretation has been applied, retaining raw input to the some
> of the interpretations if required. I want to then transmit the complete
> interpreted event to my central event repository.
>
> My proposal is that ausearch gains the following 'interpreted output'
> options
>
> --Xo plain|json|xml
> generate plain (cf --interpret), xml or json formatted events
>
> --Xr key_a'+'key_b'+'key_c
> include raw value for given keys using the the new key
> __r_key_a, __r_key_b, etc. The special key __all__ is
> interpreted to retain the complete raw record. If the raw value
> has no interpreted value, then we will end up with two keys with
> the same value.
>
> I have attached the XSD from which the XML and JSON formats could be
> defined.
>
Is there any interest in this? If is was available, would people make
use of it?
If so I can modify ausearch and generate a proposed patch over the
Christmas break.
Regards
Burn
^ permalink raw reply
* Re: [PATCH V3 2/2] audit: log failed attempts to change audit_pid configuration
From: Paul Moore @ 2015-12-22 23:47 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: linux-audit, linux-kernel, sgrubb, eparis, v.rathor, ctcard
In-Reply-To: <0fae992f25a20225e0bfae9281a978259c76330e.1450773773.git.rgb@redhat.com>
On Tuesday, December 22, 2015 04:03:07 AM Richard Guy Briggs wrote:
> 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(-)
Same as 1/2, applied to the audit next queue.
> 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;
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCH V3 1/2] audit: stop an old auditd being starved out by a new auditd
From: Paul Moore @ 2015-12-22 23:47 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: linux-audit, linux-kernel, sgrubb, eparis, v.rathor, ctcard
In-Reply-To: <c7863810b487b34ac020087083615dc8e1b3a8bf.1450773773.git.rgb@redhat.com>
On Tuesday, December 22, 2015 04:03:06 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.
>
> 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.
>
> V3: Switch audit message type from 1000 to 1300 block.
>
> 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(-)
Applied to my audit next queue for after the merge window, thanks.
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index 843540c..d820aa9 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -110,6 +110,7 @@
> #define AUDIT_SECCOMP 1326 /* Secure Computing event */
> #define AUDIT_PROCTITLE 1327 /* Proctitle emit event */
> #define AUDIT_FEATURE_CHANGE 1328 /* audit log listing feature changes
*/
> +#define AUDIT_REPLACE 1329 /* Replace auditd if this packet
unanswerd */
>
> #define AUDIT_AVC 1400 /* SE Linux avc denial or grant */
> #define AUDIT_SELINUX_ERR 1401 /* Internal SE Linux Errors */
> 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;
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCH V3 1/2] audit: stop an old auditd being starved out by a new auditd
From: Richard Guy Briggs @ 2015-12-22 15:46 UTC (permalink / raw)
To: Steve Grubb
Cc: Paul Moore, linux-audit, linux-kernel, eparis, v.rathor, ctcard
In-Reply-To: <2432137.V5S5oOaA09@x2>
On 15/12/22, Steve Grubb wrote:
> On Tuesday, December 22, 2015 09:24:56 AM Paul Moore wrote:
> > On Tuesday, December 22, 2015 04:03:06 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.
> > >
> > > 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.
> > >
> > > V3: Switch audit message type from 1000 to 1300 block.
> > >
> > > 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..d820aa9 100644
> > > --- a/include/uapi/linux/audit.h
> > > +++ b/include/uapi/linux/audit.h
> > > @@ -110,6 +110,7 @@
> > >
> > > #define AUDIT_SECCOMP 1326 /* Secure Computing event */
> > > #define AUDIT_PROCTITLE 1327 /* Proctitle emit event */
> > > #define AUDIT_FEATURE_CHANGE 1328 /* audit log listing feature changes
> >
> > */
> >
> > > +#define AUDIT_REPLACE 1329 /* Replace auditd if this packet...
> >
> > Steve, are you okay with this record number?
>
> Yes. Just wondering what to do with the event.
There's a u32 in it with the pid of the process trying to hijack/replace
the one the kernel thinks still exists, so it is worth recording that
information, I think, if the old auditd actually receives this message.
> -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 V3 1/2] audit: stop an old auditd being starved out by a new auditd
From: Steve Grubb @ 2015-12-22 14:56 UTC (permalink / raw)
To: Paul Moore
Cc: Richard Guy Briggs, linux-audit, linux-kernel, eparis, v.rathor,
ctcard
In-Reply-To: <2102911.K5vUjx9PZL@sifl>
On Tuesday, December 22, 2015 09:24:56 AM Paul Moore wrote:
> On Tuesday, December 22, 2015 04:03:06 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.
> >
> > 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.
> >
> > V3: Switch audit message type from 1000 to 1300 block.
> >
> > 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..d820aa9 100644
> > --- a/include/uapi/linux/audit.h
> > +++ b/include/uapi/linux/audit.h
> > @@ -110,6 +110,7 @@
> >
> > #define AUDIT_SECCOMP 1326 /* Secure Computing event */
> > #define AUDIT_PROCTITLE 1327 /* Proctitle emit event */
> > #define AUDIT_FEATURE_CHANGE 1328 /* audit log listing feature changes
>
> */
>
> > +#define AUDIT_REPLACE 1329 /* Replace auditd if this packet...
>
> Steve, are you okay with this record number?
Yes. Just wondering what to do with the event.
-Steve
^ permalink raw reply
* Re: [PATCH V3 1/2] audit: stop an old auditd being starved out by a new auditd
From: Paul Moore @ 2015-12-22 14:24 UTC (permalink / raw)
To: sgrubb
Cc: Richard Guy Briggs, linux-audit, linux-kernel, eparis, v.rathor,
ctcard
In-Reply-To: <c7863810b487b34ac020087083615dc8e1b3a8bf.1450773773.git.rgb@redhat.com>
On Tuesday, December 22, 2015 04:03:06 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.
>
> 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.
>
> V3: Switch audit message type from 1000 to 1300 block.
>
> 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..d820aa9 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -110,6 +110,7 @@
> #define AUDIT_SECCOMP 1326 /* Secure Computing event */
> #define AUDIT_PROCTITLE 1327 /* Proctitle emit event */
> #define AUDIT_FEATURE_CHANGE 1328 /* audit log listing feature changes
*/
> +#define AUDIT_REPLACE 1329 /* Replace auditd if this packet...
Steve, are you okay with this record number?
--
paul moore
security @ redhat
^ permalink raw reply
* [PATCH V3 2/2] audit: log failed attempts to change audit_pid configuration
From: Richard Guy Briggs @ 2015-12-22 9:03 UTC (permalink / raw)
To: linux-audit, linux-kernel; +Cc: v.rathor, Richard Guy Briggs
In-Reply-To: <c7863810b487b34ac020087083615dc8e1b3a8bf.1450773773.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 V3 1/2] audit: stop an old auditd being starved out by a new auditd
From: Richard Guy Briggs @ 2015-12-22 9:03 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.
V3: Switch audit message type from 1000 to 1300 block.
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..d820aa9 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -110,6 +110,7 @@
#define AUDIT_SECCOMP 1326 /* Secure Computing event */
#define AUDIT_PROCTITLE 1327 /* Proctitle emit event */
#define AUDIT_FEATURE_CHANGE 1328 /* audit log listing feature changes */
+#define AUDIT_REPLACE 1329 /* Replace auditd if this packet unanswerd */
#define AUDIT_AVC 1400 /* SE Linux avc denial or grant */
#define AUDIT_SELINUX_ERR 1401 /* Internal SE Linux Errors */
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: [PATCH V2 1/2] audit: stop an old auditd being starved out by a new auditd
From: Paul Moore @ 2015-12-21 22:36 UTC (permalink / raw)
To: Steve Grubb
Cc: Richard Guy Briggs, linux-audit, linux-kernel, eparis, v.rathor,
ctcard
In-Reply-To: <3132444.Y0z3o3Cmva@x2>
On Monday, December 21, 2015 05:18:15 PM Steve Grubb wrote:
> On Monday, December 21, 2015 04:48:00 PM Paul Moore wrote:
> > On Wednesday, December 16, 2015 11:23:19 AM Steve Grubb wrote:
> > > 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?
> >
> > I imagine there might be scenarios where you need to forcibly kill an
> > instance of auditd such that things might not get fully cleaned up in the
> > kernel, audit_{pid,sock,etc.}.
>
> But the first time an event is sent and auditd doesn't exist, it resets the
> audit_pid to 0.
>
> static void kauditd_send_skb(struct sk_buff *skb)
> {
> int err;
> /* take a reference in case we can't send it and we want...
> skb_get(skb);
> err = netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
> if (err < 0) {
> BUG_ON(err != -ECONNREFUSED); /* Shouldn't happen */
> if (audit_pid) {
> pr_err("*NO* daemon at audit_pid=%d\n", audit_pid);
> audit_log_lost("auditd disappeared");
> audit_pid = 0;
> audit_sock = NULL;
> }
As an aside, it doesn't matter in this particular case, but the above code is
not current. Please try to use either what is in Linus' tree or audit#next
when pasting code snippets; it's less confusing.
I still think there is some value in having the ability for an admin to reset
the kernel's auditd tracking manually as relying on an event to be emitted
does not seem like a solution I would want to have to justify. Although I do
admit that for most systems this shouldn't be a problem as events should
likely occur often enough.
There really is no harm in merging these patches, and they do provide some,
admittedly small, value.
> > Keeping the ability to reset the kernel's auditd state, even when the
> > kernel *thinks* auditd is still alive might be a nice thing to keep
> > around for a while longer.
>
> I'm just thinking its rare that anyone would try to steal away the audit
> socket. Its more work for everyone to create a new event and send it than to
> just not allow it. you can even force an event with "auditctl -m test"
> which should reset the pid if the kernel was out of sync.
I do not want to disallow starting an new instance of auditd, so this patchset
looks reasonable to me.
--
paul moore
security @ redhat
^ 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-21 22:18 UTC (permalink / raw)
To: Paul Moore
Cc: Richard Guy Briggs, linux-audit, linux-kernel, eparis, v.rathor,
ctcard
In-Reply-To: <1831194.c6xgxYyxjn@sifl>
On Monday, December 21, 2015 04:48:00 PM Paul Moore wrote:
> On Wednesday, December 16, 2015 11:23:19 AM Steve Grubb wrote:
> > 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?
>
> I imagine there might be scenarios where you need to forcibly kill an
> instance of auditd such that things might not get fully cleaned up in the
> kernel, audit_{pid,sock,etc.}.
But the first time an event is sent and auditd doesn't exist, it resets the
audit_pid to 0.
static void kauditd_send_skb(struct sk_buff *skb)
{
int err;
/* take a reference in case we can't send it and we want to hold it */
skb_get(skb);
err = netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
if (err < 0) {
BUG_ON(err != -ECONNREFUSED); /* Shouldn't happen */
if (audit_pid) {
pr_err("*NO* daemon at audit_pid=%d\n", audit_pid);
audit_log_lost("auditd disappeared");
audit_pid = 0;
audit_sock = NULL;
}
> Keeping the ability to reset the kernel's auditd state, even when the kernel
> *thinks* auditd is still alive might be a nice thing to keep around for a
> while longer.
I'm just thinking its rare that anyone would try to steal away the audit
socket. Its more work for everyone to create a new event and send it than to
just not allow it. you can even force an event with "auditctl -m test" which
should reset the pid if the kernel was out of sync.
The
> > > 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 pack...
*/
> >
> > 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.
>
> Change the audit event number as Steve suggests and I'll toss the patches
> into my audit next queue, although considering we are at 4.4-rc6 at
> present, I'll probably hold this until after the merge window closes,
> meaning it is 4.6 material.
^ permalink raw reply
* Re: [PATCH V2 1/2] audit: stop an old auditd being starved out by a new auditd
From: Paul Moore @ 2015-12-21 21:48 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Steve Grubb, linux-audit, linux-kernel, eparis, v.rathor, ctcard
In-Reply-To: <2544274.X8ZVJd57ai@x2>
On Wednesday, December 16, 2015 11:23:19 AM Steve Grubb wrote:
> 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?
I imagine there might be scenarios where you need to forcibly kill an instance
of auditd such that things might not get fully cleaned up in the kernel,
audit_{pid,sock,etc.}. Keeping the ability to reset the kernel's auditd
state, even when the kernel *thinks* auditd is still alive might be a nice
thing to keep around for a while longer.
> > 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 pack... */
>
> 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.
Change the audit event number as Steve suggests and I'll toss the patches into
my audit next queue, although considering we are at 4.4-rc6 at present, I'll
probably hold this until after the merge window closes, meaning it is 4.6
material.
--
paul moore
security @ redhat
^ permalink raw reply
* RE: Re: Use case not covered by the audit library?
From: Maupertuis Philippe @ 2015-12-21 11:04 UTC (permalink / raw)
To: linux-audit@redhat.com
I am new to the subject of user audit record.
I have some newbie questions.
Is it possible to generate these records in any language , python or java for example ?
Where can I find example or newbie documentation ?
Regards
Philippe
-----Message d'origine-----
De : linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] De la part de linux-audit-request@redhat.com
Envoyé : vendredi 18 décembre 2015 18:00
À : linux-audit@redhat.com
Objet : Linux-audit Digest, Vol 135, Issue 9
Send Linux-audit mailing list submissions to
linux-audit@redhat.com
To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/linux-audit
or, via email, send a message with subject or body 'help' to
linux-audit-request@redhat.com
You can reach the person managing the list at
linux-audit-owner@redhat.com
When replying, please edit your Subject line so it is more specific than "Re: Contents of Linux-audit digest..."
Today's Topics:
1. Re: Use case not covered by the audit library? (Steve Grubb)
2. Simple bug fix for PROCTITLE not being recognised with
ausearch --debug check (Burn Alting)
3. Re: New draft standards (Burn Alting)
4. Re: Simple bug fix for PROCTITLE not being recognised with
ausearch --debug check (Steve Grubb)
----------------------------------------------------------------------
Message: 1
Date: Thu, 17 Dec 2015 21:51:15 -0500
From: Steve Grubb <sgrubb@redhat.com>
To: "Gulland, Scott A" <scott.gulland@hpe.com>
Cc: Richard Guy Briggs <rgb@redhat.com>, "linux-audit@redhat.com"
<linux-audit@redhat.com>
Subject: Re: Use case not covered by the audit library?
Message-ID: <1484204.GzGFVCTWQh@x2>
Content-Type: text/plain; charset="us-ascii"
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
------------------------------
Message: 2
Date: Fri, 18 Dec 2015 14:20:44 +1100
From: Burn Alting <burn@swtf.dyndns.org>
To: "linux-audit@redhat.com" <linux-audit@redhat.com>
Subject: Simple bug fix for PROCTITLE not being recognised with
ausearch --debug check
Message-ID: <1450408844.14944.4.camel@swtf.swtf.dyndns.org>
Content-Type: text/plain; charset="utf-8"
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: audit-2.4.4_debug_fix.patch
Type: text/x-patch
Size: 455 bytes
Desc: not available
URL: <https://www.redhat.com/archives/linux-audit/attachments/20151218/0a543af4/attachment.bin>
------------------------------
Message: 3
Date: Fri, 18 Dec 2015 16:12:08 +1100
From: Burn Alting <burn@swtf.dyndns.org>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: New draft standards
Message-ID: <1450415528.14944.28.camel@swtf.swtf.dyndns.org>
Content-Type: text/plain; charset="utf-8"
On Tue, 2015-12-15 at 08:46 -0500, Steve Grubb wrote:
> 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.
>
All,
To reiterate, my need is to generate easy to parse events over which local interpretation has been applied, retaining raw input to the some of the interpretations if required. I want to then transmit the complete interpreted event to my central event repository.
My proposal is that ausearch gains the following 'interpreted output'
options
--Xo plain|json|xml
generate plain (cf --interpret), xml or json formatted events
--Xr key_a'+'key_b'+'key_c
include raw value for given keys using the the new key
__r_key_a, __r_key_b, etc. The special key __all__ is
interpreted to retain the complete raw record. If the raw value
has no interpreted value, then we will end up with two keys with
the same value.
I have attached the XSD from which the XML and JSON formats could be defined.
The following provides some examples.
For the raw event (on a system recording execve's and with name_format = fqd configured)
node=fedora23.a1959.org type=SYSCALL msg=audit(1450409042.880:61882):
arch=c000003e syscall=59 success=yes exit=0 a0=561c5e714d60
a1=561c5e6dbb90 a2=561c5e630920 a3=561c5e6dbb80 items=2 ppid=27269
pid=29282 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts0 ses=8 comm="ausearch" exe="/usr/sbin/ausearch"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="cmds"
node=fedora23.a1959.org type=EXECVE msg=audit(1450409042.880:61882):
argc=4 a0="ausearch" a1="-i" a2="-if" a3="/var/log/audit/audit.log"
node=fedora23.a1959.org type=CWD msg=audit(1450409042.880:61882):
cwd="/home/burn/audit-2.4.4_debug_fix"
node=fedora23.a1959.org type=PATH msg=audit(1450409042.880:61882):
item=0 name="/sbin/ausearch" inode=134573468 dev=fd:00 mode=0100755
ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL node=fedora23.a1959.org type=PATH msg=audit(1450409042.880:61882):
item=1 name="/lib64/ld-linux-x86-64.so.2" inode=134397639 dev=fd:00
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL node=fedora23.a1959.org type=PROCTITLE msg=audit(1450409042.880:61882):
proctitle=6175736561726368002D69002D6966002F7661722F6C6F672F61756469742F61756469742E6C6F67
Running ausearch with the proposed changes becomes, for --Xo plain
node=fedora23.a1959.org type=PROCTITLE msg=audit(12/18/2015
14:24:02.880:61882) : proctitle=ausearch -i -if /var/log/audit/audit.log node=fedora23.a1959.org type=PATH msg=audit(12/18/2015
14:24:02.880:61882) : item=1 name=/lib64/ld-linux-x86-64.so.2
inode=134397639 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00
obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL node=fedora23.a1959.org type=PATH msg=audit(12/18/2015
14:24:02.880:61882) : item=0 name=/sbin/ausearch inode=134573468
dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00
obj=system_u:object_r:bin_t:s0 nametype=NORMAL node=fedora23.a1959.org type=CWD msg=audit(12/18/2015
14:24:02.880:61882) : cwd=/home/burn/audit-2.4.4_debug_fix
node=fedora23.a1959.org type=EXECVE msg=audit(12/18/2015
14:24:02.880:61882) : argc=4 a0=ausearch a1=-i a2=-if a3=/var/log/audit/audit.log node=fedora23.a1959.org type=SYSCALL msg=audit(12/18/2015
14:24:02.880:61882) : arch=x86_64 syscall=execve success=yes exit=0
a0=0x561c5e714d60 a1=0x561c5e6dbb90 a2=0x561c5e630920 a3=0x561c5e6dbb80
items=2 ppid=27269 pid=29282 auid=burn uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=8 comm=ausearch exe=/usr/sbin/ausearch
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=cmds
and, for --Xo xml
<event>
<node>fedora23.a1959.org</node>
<time>2015-12-18T14:24:02.880+11:00</time>
<serial>1450409042.880:61882</serial>
<records>
<record>
<type>PROCTITLE</type>
<data name="proctitle" value="ausearch -i -if /var/log/audit/audit.log" />
</record>
<record>
<type>PATH</type>
<data name="item" value="1" />
<data name="name" value="/lib64/ld-linux-x86-64.so.2" />
<data name="inode" value="134397639" />
<data name="dev" value="fd:00" />
...
<data name="nametype" value="NORMAL" />
</record>
...
<record>
<type>SYSCALL</type>
<data name="arch" value="x86_64" />
<data name="syscall" value="execve" />
..
<data name="subj"
value="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023" />
<data name="key" value="cmds" />
</record>
</records>
</event>
and, for --Xo json
{
"event": {
"node": "fedora23.a1959.org",
"time": "2015-12-18T14:24:02.880+11:00",
"serial": "1450409042.880:61882",
"records": {
"record": [
{
"type": "PROCTITLE",
"data": {
"_name": "proctitle",
"_value": "ausearch -i -if /var/log/audit/audit.log"
}
},
{
"type": "PATH",
"data": [
{
"_name": "item",
"_value": "1"
},
{
"_name": "name",
"_value": "/lib64/ld-linux-x86-64.so.2"
},
{
"_name": "inode",
"_value": "134397639"
},
{
"_name": "dev",
"_value": "fd:00"
},
...
{
"_name": "nametype",
"_value": "NORMAL"
}
]
},
...
{
"type": "SYSCALL",
"data": [
{
"_name": "arch",
"_value": "x86_64"
},
{
"_name": "syscall",
"_value": "execve"
},
...
{
"_name": "subj",
"_value":
"unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023"
},
{
"_name": "key",
"_value": "cmds"
}
]
}
]
}
}
}
Specifying --Xr __all__ does nothing for plain, but for xml adds a raw element within each record, as per
...
<records>
<record>
<type>PROCTITLE</type>
<raw>node=fedora23.a1959.org type=PROCTITLE
msg=audit(1450409042.880:61882):
proctitle=6175736561726368002D69002D6966002F7661722F6C6F672F61756469742F61756469742E6C6F67</raw>
...
</record>
<record>
<type>PATH</type>
<raw>node=fedora23.a1959.org type=PATH
msg=audit(1450409042.880:61882): item=1
name="/lib64/ld-linux-x86-64.so.2" inode=134397639 dev=fd:00
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL</raw>
...
and for json adds a raw key within each record, as per
"record": [
{
"type": "PROCTITLE",
"raw": "node=fedora23.a1959.org type=PROCTITLE
msg=audit(1450409042.880:61882):
proctitle=6175736561726368002D69002D6966002F7661722F6C6F672F61756469742F61756469742E6C6F67",
"data": {
"_name": "proctitle",
"_value": "ausearch -i -if /var/log/audit/audit.log"
}
},
{
"type": "PATH",
"raw": "node=fedora23.a1959.org type=PATH
msg=audit(1450409042.880:61882): item=1 name= \"/lib64/ld-linux-x86-64.so.2\" inode=134397639 dev=fd:00 mode=0100755
ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL",
"data": [
{
...
And if you want arbitrary raw key values as well as their interpreted value, then provide a '+' separated list of keys. For example,
--Xr auid|syscall|a2
applied to the following raw record
node=fedora23.a1959.org type=SYSCALL msg=audit(1450410618.410:62231):
arch=c000003e syscall=268 success=yes exit=0 a0=ffffffffffffff9c
a1=562de17c80f0 a2=1e8 a3=fffff3ff items=1 ppid=27269 pid=29705
auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts0 ses=8 comm="chmod" exe="/usr/bin/chmod"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
key="perm_mod"
for --Xo plain, we get
node=fedora23.a1959.org type=SYSCALL msg=audit(12/18/2015
14:50:18.410:62231) : arch=x86_64 syscall=fchmodat success=yes exit=0 a0=0xffffffffffffff9c a1=0x562de17c80f0 a2=0750 a3=0xfffff3ff items=1
ppid=27269 pid=29705 auid=burn uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=8 comm=chmod exe=/usr/bin/chmod
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=perm_mod
__r_syscall=268 __r_auid=1000 __r_a2=1e8
for --Xo xml
...
<data name="syscall" value="fchmodat" />
...
<data name="key" value="perm_mod" />
<data name="__r_syscall" value="268" />
<data name="__r_auid" value="1000" />
<data name="__r_a2" value="1e8" />
for --Xo json
...
{
"_name": "syscall",
"_value": "fchmodat"
},
...
},
{
"_name": "key",
"_value": "perm_mod"
},
{
"_name": "__r_syscall",
"_value": "268"
},
{
"_name": "__r_auid",
"_value": "1000"
},
{
"_name": "__r_a2",
"_value": "1e8"
}
]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ausearch.xsd
Type: application/xml
Size: 5875 bytes
Desc: not available
URL: <https://www.redhat.com/archives/linux-audit/attachments/20151218/f13548d6/attachment.rdf>
------------------------------
Message: 4
Date: Fri, 18 Dec 2015 09:00:41 -0500
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com, burn@swtf.dyndns.org
Subject: Re: Simple bug fix for PROCTITLE not being recognised with
ausearch --debug check
Message-ID: <2718949.1R5FipW8Ma@x2>
Content-Type: text/plain; charset="us-ascii"
On Friday, December 18, 2015 02:20:44 PM Burn Alting wrote:
> 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.
Thanks! Applied.
-Steve
------------------------------
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
End of Linux-audit Digest, Vol 135, Issue 9
*******************************************
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
^ permalink raw reply
* Re: [PATCH 00/15] Rework tty audit
From: Paul Moore @ 2015-12-21 0:39 UTC (permalink / raw)
To: Peter Hurley
Cc: Peter Zijlstra, Greg Kroah-Hartman, Oleg Nesterov, linux-audit,
Jiri Slaby, Ingo Molnar
In-Reply-To: <1447207560-16410-1-git-send-email-peter@hurleysoftware.com>
On Tuesday, November 10, 2015 09:05:45 PM Peter Hurley wrote:
> Hi Greg,
>
> This patch series overhauls tty audit support. The goal was to simplify
> and speed up tty auditing, which was a significant performance hit even
> when disabled.
>
> The main features of this series are:
> * Remove reference counting; the purpose of reference counting the per-
> process tty_audit_buf was to prevent premature deletion if the
> buffer was in-use when tty auditing was exited for the process.
> However, since the process is single-threaded at tty_audit_exit(),
> the buffer cannot be in-use by another thread. Patch 11/15.
> * Remove functionally dead code, such as tty_put_user(). Patch 2/15.
> * Atomically modify tty audit enable/disable flags to support lockless
> read. Patch 9/15.
>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> for patch 9/15 which removes an audit field from the signal_struct.
>
> Cc: Oleg Nesterov <oleg@redhat.com>
> to confirm my understanding of the single-threadedness of
> if (group_dead) tty_audit_exit(), called from do_exit(). Patch 11/15
>
> Requires: "tty: audit: Fix audit source"
This is definitely more of a tty patchset than it is an audit patchset, but it
all looks reasonable to me from an audit perspective.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: audit 2.4.5 released
From: Paul Moore @ 2015-12-18 23:32 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <1882622.eTClln5m29@x2>
On Fri, Dec 18, 2015 at 4:20 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Friday, December 18, 2015 04:08:07 PM Paul Moore wrote:
>> On Fri, Dec 18, 2015 at 2:49 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>> > Hello,
>> >
>> > I've just released a new version of the audit daemon. It can be downloaded
>> > from http://people.redhat.com/sgrubb/audit. It will also be in rawhide
>> > soon. The ChangeLog is:
>> >
>> > - Fix auditd disk flushing for data and sync modes
>> > - Fix auditctl to not show options not supported on older OS
>> > - Add audit.m4 file to aid adding support to other projects
>> > - Fix C99 inline function build issue
>> > - Add account lock and unlock event types
>> > - Change logging loophole check to geteuid()
>> > - Fix ausearch to not consider AUDIT_PROCTITLE events malformed (Burn
>> > Alting) - Fix ausearch to parse FEATURE_CHANGE events
>>
>> Perhaps I missed it, but when can we expect the audit-by-exec support?
>
> It will be in the 2.5 release. It should be one of the first couple of things I
> apply to the svn repo. I'm going to shoot for a January release of the audit
> package.
Okay, thanks for the update.
In the future I'd like us to coordinate a bit better when adding new
features that span kernel and userspace; I dislike implementing new
features in the kernel that lay dormant for a release or two.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: audit 2.4.5 released
From: Steve Grubb @ 2015-12-18 21:20 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <CAHC9VhR-WYVT42dP6k4Yfu-JcvshM2Q7+Q=coK5zmN_fWuxPGA@mail.gmail.com>
On Friday, December 18, 2015 04:08:07 PM Paul Moore wrote:
> On Fri, Dec 18, 2015 at 2:49 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > Hello,
> >
> > I've just released a new version of the audit daemon. It can be downloaded
> > from http://people.redhat.com/sgrubb/audit. It will also be in rawhide
> > soon. The ChangeLog is:
> >
> > - Fix auditd disk flushing for data and sync modes
> > - Fix auditctl to not show options not supported on older OS
> > - Add audit.m4 file to aid adding support to other projects
> > - Fix C99 inline function build issue
> > - Add account lock and unlock event types
> > - Change logging loophole check to geteuid()
> > - Fix ausearch to not consider AUDIT_PROCTITLE events malformed (Burn
> > Alting) - Fix ausearch to parse FEATURE_CHANGE events
>
> Perhaps I missed it, but when can we expect the audit-by-exec support?
It will be in the 2.5 release. It should be one of the first couple of things I
apply to the svn repo. I'm going to shoot for a January release of the audit
package.
-Steve
^ permalink raw reply
* Re: audit 2.4.5 released
From: Paul Moore @ 2015-12-18 21:08 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <1929164.Q9DeV9IFDj@x2>
On Fri, Dec 18, 2015 at 2:49 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> Hello,
>
> I've just released a new version of the audit daemon. It can be downloaded
> from http://people.redhat.com/sgrubb/audit. It will also be in rawhide
> soon. The ChangeLog is:
>
> - Fix auditd disk flushing for data and sync modes
> - Fix auditctl to not show options not supported on older OS
> - Add audit.m4 file to aid adding support to other projects
> - Fix C99 inline function build issue
> - Add account lock and unlock event types
> - Change logging loophole check to geteuid()
> - Fix ausearch to not consider AUDIT_PROCTITLE events malformed (Burn Alting)
> - Fix ausearch to parse FEATURE_CHANGE events
Perhaps I missed it, but when can we expect the audit-by-exec support?
--
paul moore
www.paul-moore.com
^ permalink raw reply
* audit 2.4.5 released
From: Steve Grubb @ 2015-12-18 19:49 UTC (permalink / raw)
To: linux-audit
Hello,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit. It will also be in rawhide
soon. The ChangeLog is:
- Fix auditd disk flushing for data and sync modes
- Fix auditctl to not show options not supported on older OS
- Add audit.m4 file to aid adding support to other projects
- Fix C99 inline function build issue
- Add account lock and unlock event types
- Change logging loophole check to geteuid()
- Fix ausearch to not consider AUDIT_PROCTITLE events malformed (Burn Alting)
- Fix ausearch to parse FEATURE_CHANGE events
This release fixes disk flushing to work as it was intended. If you use either
the data or sync mode, you might notice a performance change.
This release also fixes a build issue when using a new compiler.
The loophole that we allow for a process to continue when it should fail was
changed to use the euid rather than the uid. This should be more correct based
on the capabilities man page.
Ausearch was having problems parsing AUDIT_PROCTITLE and FEATURE_CHANGE
events. This was cleaned up and now passed the ausearch-test test suite.
This release will also be the beginning point of a new branch, audit-2.4, that
will be lightly maintained for a while. At this point I don't think there will
be a 2.4.6 release, but you never know.
Going forward to the 2.5 release, I would like to make a lot of changes to the
rules and break them up into small ones that can be assembled by augenrules. I
will also restructure a few of the directories and get things ready to start
doing more with the data format. The audit by process name patch will be
applied real soon since a kernel with that work should be landing soon.
Please let me know if you run across any problems with this release.
-Steve
^ permalink raw reply
* Re: Simple bug fix for PROCTITLE not being recognised with ausearch --debug check
From: Steve Grubb @ 2015-12-18 14:00 UTC (permalink / raw)
To: linux-audit, burn
In-Reply-To: <1450408844.14944.4.camel@swtf.swtf.dyndns.org>
On Friday, December 18, 2015 02:20:44 PM Burn Alting wrote:
> 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.
Thanks! Applied.
-Steve
^ permalink raw reply
* Re: New draft standards
From: Burn Alting @ 2015-12-18 5:12 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <8060196.OPZyc9AaGl@x2>
[-- Attachment #1: Type: text/plain, Size: 9924 bytes --]
On Tue, 2015-12-15 at 08:46 -0500, Steve Grubb wrote:
> 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.
>
All,
To reiterate, my need is to generate easy to parse events over which
local interpretation has been applied, retaining raw input to the some
of the interpretations if required. I want to then transmit the complete
interpreted event to my central event repository.
My proposal is that ausearch gains the following 'interpreted output'
options
--Xo plain|json|xml
generate plain (cf --interpret), xml or json formatted events
--Xr key_a'+'key_b'+'key_c
include raw value for given keys using the the new key
__r_key_a, __r_key_b, etc. The special key __all__ is
interpreted to retain the complete raw record. If the raw value
has no interpreted value, then we will end up with two keys with
the same value.
I have attached the XSD from which the XML and JSON formats could be
defined.
The following provides some examples.
For the raw event (on a system recording execve's and with name_format =
fqd configured)
node=fedora23.a1959.org type=SYSCALL msg=audit(1450409042.880:61882):
arch=c000003e syscall=59 success=yes exit=0 a0=561c5e714d60
a1=561c5e6dbb90 a2=561c5e630920 a3=561c5e6dbb80 items=2 ppid=27269
pid=29282 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts0 ses=8 comm="ausearch" exe="/usr/sbin/ausearch"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="cmds"
node=fedora23.a1959.org type=EXECVE msg=audit(1450409042.880:61882):
argc=4 a0="ausearch" a1="-i" a2="-if" a3="/var/log/audit/audit.log"
node=fedora23.a1959.org type=CWD msg=audit(1450409042.880:61882):
cwd="/home/burn/audit-2.4.4_debug_fix"
node=fedora23.a1959.org type=PATH msg=audit(1450409042.880:61882):
item=0 name="/sbin/ausearch" inode=134573468 dev=fd:00 mode=0100755
ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL
node=fedora23.a1959.org type=PATH msg=audit(1450409042.880:61882):
item=1 name="/lib64/ld-linux-x86-64.so.2" inode=134397639 dev=fd:00
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0
nametype=NORMAL
node=fedora23.a1959.org type=PROCTITLE msg=audit(1450409042.880:61882):
proctitle=6175736561726368002D69002D6966002F7661722F6C6F672F61756469742F61756469742E6C6F67
Running ausearch with the proposed changes becomes, for --Xo plain
node=fedora23.a1959.org type=PROCTITLE msg=audit(12/18/2015
14:24:02.880:61882) : proctitle=ausearch -i
-if /var/log/audit/audit.log
node=fedora23.a1959.org type=PATH msg=audit(12/18/2015
14:24:02.880:61882) : item=1 name=/lib64/ld-linux-x86-64.so.2
inode=134397639 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00
obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL
node=fedora23.a1959.org type=PATH msg=audit(12/18/2015
14:24:02.880:61882) : item=0 name=/sbin/ausearch inode=134573468
dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00
obj=system_u:object_r:bin_t:s0 nametype=NORMAL
node=fedora23.a1959.org type=CWD msg=audit(12/18/2015
14:24:02.880:61882) : cwd=/home/burn/audit-2.4.4_debug_fix
node=fedora23.a1959.org type=EXECVE msg=audit(12/18/2015
14:24:02.880:61882) : argc=4 a0=ausearch a1=-i a2=-if
a3=/var/log/audit/audit.log
node=fedora23.a1959.org type=SYSCALL msg=audit(12/18/2015
14:24:02.880:61882) : arch=x86_64 syscall=execve success=yes exit=0
a0=0x561c5e714d60 a1=0x561c5e6dbb90 a2=0x561c5e630920 a3=0x561c5e6dbb80
items=2 ppid=27269 pid=29282 auid=burn uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=8
comm=ausearch exe=/usr/sbin/ausearch
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=cmds
and, for --Xo xml
<event>
<node>fedora23.a1959.org</node>
<time>2015-12-18T14:24:02.880+11:00</time>
<serial>1450409042.880:61882</serial>
<records>
<record>
<type>PROCTITLE</type>
<data name="proctitle" value="ausearch -i
-if /var/log/audit/audit.log" />
</record>
<record>
<type>PATH</type>
<data name="item" value="1" />
<data name="name" value="/lib64/ld-linux-x86-64.so.2" />
<data name="inode" value="134397639" />
<data name="dev" value="fd:00" />
...
<data name="nametype" value="NORMAL" />
</record>
...
<record>
<type>SYSCALL</type>
<data name="arch" value="x86_64" />
<data name="syscall" value="execve" />
..
<data name="subj"
value="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023" />
<data name="key" value="cmds" />
</record>
</records>
</event>
and, for --Xo json
{
"event": {
"node": "fedora23.a1959.org",
"time": "2015-12-18T14:24:02.880+11:00",
"serial": "1450409042.880:61882",
"records": {
"record": [
{
"type": "PROCTITLE",
"data": {
"_name": "proctitle",
"_value": "ausearch -i -if /var/log/audit/audit.log"
}
},
{
"type": "PATH",
"data": [
{
"_name": "item",
"_value": "1"
},
{
"_name": "name",
"_value": "/lib64/ld-linux-x86-64.so.2"
},
{
"_name": "inode",
"_value": "134397639"
},
{
"_name": "dev",
"_value": "fd:00"
},
...
{
"_name": "nametype",
"_value": "NORMAL"
}
]
},
...
{
"type": "SYSCALL",
"data": [
{
"_name": "arch",
"_value": "x86_64"
},
{
"_name": "syscall",
"_value": "execve"
},
...
{
"_name": "subj",
"_value":
"unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023"
},
{
"_name": "key",
"_value": "cmds"
}
]
}
]
}
}
}
Specifying --Xr __all__ does nothing for plain, but for xml adds a raw
element within each record, as per
...
<records>
<record>
<type>PROCTITLE</type>
<raw>node=fedora23.a1959.org type=PROCTITLE
msg=audit(1450409042.880:61882):
proctitle=6175736561726368002D69002D6966002F7661722F6C6F672F61756469742F61756469742E6C6F67</raw>
...
</record>
<record>
<type>PATH</type>
<raw>node=fedora23.a1959.org type=PATH
msg=audit(1450409042.880:61882): item=1
name="/lib64/ld-linux-x86-64.so.2" inode=134397639 dev=fd:00
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0
nametype=NORMAL</raw>
...
and for json adds a raw key within each record, as per
"record": [
{
"type": "PROCTITLE",
"raw": "node=fedora23.a1959.org type=PROCTITLE
msg=audit(1450409042.880:61882):
proctitle=6175736561726368002D69002D6966002F7661722F6C6F672F61756469742F61756469742E6C6F67",
"data": {
"_name": "proctitle",
"_value": "ausearch -i -if /var/log/audit/audit.log"
}
},
{
"type": "PATH",
"raw": "node=fedora23.a1959.org type=PATH
msg=audit(1450409042.880:61882): item=1 name=
\"/lib64/ld-linux-x86-64.so.2\" inode=134397639 dev=fd:00 mode=0100755
ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0
nametype=NORMAL",
"data": [
{
...
And if you want arbitrary raw key values as well as their interpreted
value, then provide a '+' separated list of keys. For example,
--Xr auid|syscall|a2
applied to the following raw record
node=fedora23.a1959.org type=SYSCALL msg=audit(1450410618.410:62231):
arch=c000003e syscall=268 success=yes exit=0 a0=ffffffffffffff9c
a1=562de17c80f0 a2=1e8 a3=fffff3ff items=1 ppid=27269 pid=29705
auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts0 ses=8 comm="chmod" exe="/usr/bin/chmod"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
key="perm_mod"
for --Xo plain, we get
node=fedora23.a1959.org type=SYSCALL msg=audit(12/18/2015
14:50:18.410:62231) : arch=x86_64 syscall=fchmodat success=yes exit=0
a0=0xffffffffffffff9c a1=0x562de17c80f0 a2=0750 a3=0xfffff3ff items=1
ppid=27269 pid=29705 auid=burn uid=root gid=root euid=root suid=root
fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=8 comm=chmod
exe=/usr/bin/chmod
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=perm_mod
__r_syscall=268 __r_auid=1000 __r_a2=1e8
for --Xo xml
...
<data name="syscall" value="fchmodat" />
...
<data name="key" value="perm_mod" />
<data name="__r_syscall" value="268" />
<data name="__r_auid" value="1000" />
<data name="__r_a2" value="1e8" />
for --Xo json
...
{
"_name": "syscall",
"_value": "fchmodat"
},
...
},
{
"_name": "key",
"_value": "perm_mod"
},
{
"_name": "__r_syscall",
"_value": "268"
},
{
"_name": "__r_auid",
"_value": "1000"
},
{
"_name": "__r_a2",
"_value": "1e8"
}
]
[-- Attachment #2: ausearch.xsd --]
[-- Type: application/xml, Size: 5875 bytes --]
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* 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
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