* Re: Problem running auditd on Raspberry Pi (fedora-server-24)
From: Steve Grubb @ 2016-10-04 15:10 UTC (permalink / raw)
To: C.y; +Cc: linux-audit
In-Reply-To: <CABYhOsxYcj_oYiThrzA3sg_EXF58hVVaKuNRD8Bmzsp_m6azaQ@mail.gmail.com>
On Tuesday, October 4, 2016 11:35:46 AM EDT C.y wrote:
> On Tue, Oct 4, 2016 at 4:06 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Sunday, October 2, 2016 11:00:16 AM EDT C.y wrote:
> > > On Sun, Oct 2, 2016 at 12:20 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > > On Saturday, October 1, 2016 5:47:47 PM EDT C.y wrote:
> > > > > Hi all,
> > > > >
> > > > >
> > > > > I have fedora-server-24 installed on my raspberry-pi-3, following
> > > > > the
> > > > > guide https://fedoraproject.org/wiki/Raspberry_Pi.
> > > > >
> > > > > Once I get my raspberry pi boot up, there were error mentioning that
> > > > > "audit not support not in kernel", which I believed were then
> >
> > resolved after I
> >
> > > > > rebuild my kernel.
> > > > >
> > > > > However, I got stuck when I tried to add rule using `auditctl`
> >
> > command
> >
> > > > > as below:
> > > > > `# auditctl -w /etc/passwd -p wa -k passwd_changes`
> > > > > Error sending add rule data request (Invalid argument)
> > > >
> > > > Hmm. I wonder if 'ausyscall open' gives you syscalls.
> > >
> > > `# ausyscall open` returns as below. So I suppose the answer is
> > > yes?(correct me if I'm wrong)
> > > open 5
> > > mq_open 274
> > > openat 322
> > > perf_event_open 364
> > > open_by_handle_at 371
> >
> > This means user space is doing the right thing. I am thinking this sounds
> > like a kernel issue.
> >
> > Have you tried a few other simple commands?
> >
> > auditctl -e 1
> > auditctl -s
> > auditctl -always,exit -F arch=b64 -S open
> >
> > -Steve
>
> `# auditctl -e 1` returns:
> enabled 1
> failure 1
> pid 293
> rate_limit 0
> backlog_limit 64
> lost 11
> backlog 0
> backlog_wait_time 6000
>
> `# auditctl -s` returns:
> enabled 1
> failure 1
> pid 293
> rate_limit 0
> backlog_limit 64
> lost 11
> backlog 0
> backlog_wait_time 6000
OK. So, this sounds like it can communicate with the kernel and part of the
audit system is compiled in.
> `# auditctl -a always,exit -F arch=b64 -S open` returns:
> arch elf mapping not found
OK. Maybe its not 64 bit.
> `# auditctl -a always,exit -S open` returns:
> Error sending add rule data request (Invalid argument)
If it were 32 bit, then the above would have selected -F arch=b32
automatically. The error message means the kernel rejected a field in the audit
rule. Which field, I don't know.
> I also noticed that auditd is having difficulty in parsing
> `/etc/auditd/auditd.rules`
> on the booting stage,
> `# journalctl -u auditd.service --this-boot` returns:
> -- Logs begin at Fri 2016-02-12 00:28:01 CST, end at Tue 2016-10-04
> 10:53:05 CST. --
> Feb 12 00:28:06 raspi3.lab systemd[1]: Starting Security Auditing Service...
> Feb 12 00:28:06 raspi3.lab auditd[287]: Started dispatcher: /sbin/audispd
> pid: 301
> Feb 12 00:28:06 raspi3.lab audispd[301]: priority_boost_parser called with:
> 4
> Feb 12 00:28:06 raspi3.lab augenrules[288]: /sbin/augenrules: No change
> Feb 12 00:28:06 raspi3.lab audispd[301]: max_restarts_parser called with: 10
> Feb 12 00:28:06 raspi3.lab augenrules[288]: Error sending add rule data
> request (Invalid argument)
> Feb 12 00:28:06 raspi3.lab augenrules[288]: There was an error in line 5 of
> /etc/audit/audit.rules
I believe this is just saying that the rule in line 5 was rejected by the
kernel. This is systemd induced. The Error sending rule message went to
stderr, auditctl also logs to syslog that it had a problem. Systemd grabs both
and logs them. So, this is really 2 messages for the same thing. Its not a
parsing problem per se.
-Steve
> Feb 12 00:28:06 raspi3.lab augenrules[288]: No rules
> Feb 12 00:28:06 raspi3.lab systemd[1]: Started Security Auditing Service.
> Feb 12 00:28:06 raspi3.lab auditd[287]: Init complete, auditd 2.5.2
> listening for events (startup state
>
> while `# cat /etc/audit/rules.d` returns:
> -----
> ## This file is automatically generated from /etc/audit/rules.d
> -D
>
>
> -a task,never
> -----
>
> p/s: On the log above, RaspberryPi is showing the wrong time due to a
> reboot,
> the time will be corrected once the chronyd start functioning.
>
>
> Regards,
> CHING YI.
>
> > > > > I tried to search for solution but it lead me to a bug that were
> >
> > already
> >
> > > > > been solved like years ago. Can anyone tell me if I am in the right
> >
> > way
> >
> > > > > of getting auditd works on raspberry pi? Were the problem I've faced
> >
> > were
> >
> > > > > already a known issue?
> > > > >
> > > > > Below are my system information and some logs/details when I tried
> > > > > to
> > > > > diagnosis the problem and thanks a lot for your help in advance!
> > > > >
> > > > > `# uname -a`
> > > > > Linux raspi3.lab 4.4.23-v7+ #2 SMP Sat Oct 1 15:24:41 CST 2016
> > > > > armv7l
> > > > > armv7l armv7l GNU/Linux
> > > >
> > > > I also wonder if we have a mismatch here. Is that armv seventy one or
> >
> > armv
> >
> > > > seven-el? Its coded in audit as seventy one.
> > >
> > > It's 7-el.
> > > `# uname -a | grep 7l` (7-el) returns
> > > Linux raspi3.lab 4.4.23-v7+ #2 SMP Sat Oct 1 15:24:41 CST 2016 armv7l
> > > armv7l armv7l GNU/Linux
> > >
> > >
> > > Sincerly,
> > > CHING YI.
> > >
> > > > -Steve
> > > >
> > > > > `# modprobe configs ; gunzip -dc /proc/config.gz | grep AUDIT`
> > > > > CONFIG_AUDIT=y
> > > > > CONFIG_NETFILTER_XT_TARGET_AUDIT=m
> > > > > CONFIG_AUDIT_GENERIC=y
> > > > > # CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
> > > > >
> > > > > `# systemctl status auditd.service`
> > > > > ● auditd.service - Security Auditing Service
> > > > >
> > > > > Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled;
> > > > >
> > > > > vendor preset: enabled)
> > > > >
> > > > > Active: active (running) since Fri 2016-02-12 00:28:07 CST; 7
> >
> > months
> >
> > > > > 19 days ago
> > > > >
> > > > > Process: 1553 ExecReload=/bin/kill -HUP $MAINPID (code=exited,
> > > > >
> > > > > status=0/SUCCESS)
> > > > >
> > > > > Process: 279 ExecStartPost=/sbin/augenrules --load (code=exited,
> > > > >
> > > > > status=1/FAILURE)
> > > > > Main PID: 278 (auditd)
> > > > >
> > > > > CGroup: /system.slice/auditd.service
> > > > >
> > > > > └─278 /sbin/auditd -n
> > > > >
> > > > > Oct 01 16:36:53 raspi3.lab auditd[278]: audit(1475311013.356:8458)
> > > > > op=reconfigure state=changed auid=4294967295 pid=-1 subj=?
> >
> > res=success
> >
> > > > > Oct 01 16:36:53 raspi3.lab systemd[1]: Reloaded Security Auditing
> > > > > Service.
> > > > > Oct 01 16:37:28 raspi3.lab systemd[1]: Reloading Security Auditing
> > > > > Service.
> > > > > Oct 01 16:37:28 raspi3.lab auditd[278]: config change requested by
> > > > > pid=-1
> > > > > auid=4294967295 subj=?
> > > > > Oct 01 16:37:28 raspi3.lab auditd[278]: audit(1475311048.046:257)
> > > > > op=reconfigure state=changed auid=4294967295 pid=-1 subj=?
> >
> > res=success
> >
> > > > > Oct 01 16:37:28 raspi3.lab systemd[1]: Reloaded Security Auditing
> > > > > Service.
> > > > > Oct 01 16:38:18 raspi3.lab systemd[1]: Reloading Security Auditing
> > > > > Service.
> > > > > Oct 01 16:38:18 raspi3.lab auditd[278]: config change requested by
> > > > > pid=-1
> > > > > auid=4294967295 subj=?
> > > > > Oct 01 16:38:18 raspi3.lab auditd[278]: audit(1475311098.716:2108)
> > > > > op=reconfigure state=changed auid=4294967295 pid=-1 subj=?
> >
> > res=success
> >
> > > > > Oct 01 16:38:18 raspi3.lab systemd[1]: Reloaded Security Auditing
> > > > > Service.
> > > > >
> > > > > While my `/var/log/audit/audit.log` was full with lines of
> > > > > "SERVICE_START" & "SERVICE_STOP":
> > > > > type=SERVICE_START msg=audit(1475313700.696:276): pid=1 uid=0
> > > > > auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher
> > > > > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
> > > > > terminal=? res=success'
> > > > > type=SERVICE_STOP msg=audit(1475313710.836:277): pid=1 uid=0
> > > > > auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher
> > > > > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
> > > > > terminal=? res=success'
> > > > >
> > > > >
> > > > > Sincerly,
> > > > > CHING YI.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: LOG_WARN or LOG_WARNING?
From: Ryan Sawhill @ 2016-10-04 15:04 UTC (permalink / raw)
To: leam hall; +Cc: linux-audit
In-Reply-To: <CACv9p5ov558kB4Hv2pBciqWi8033VV6DBT__OVWT=zzJMcCk-Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 443 bytes --]
On Tue, Oct 4, 2016 at 10:58 AM, leam hall <leamhall@gmail.com> wrote:
> Sort of a followup question. I'm surprised adding "audit.none" to the
> "/var/log/messages" line of rsyslog.conf (RHEL 6) works. I didn't think
> audit was a full "facility" in whatever rsyslog looks at. Am I more
> confused than normal?
>
It's not. If you look at your main log you should see a message from
rsyslogd saying something like "unknown facility 'audit'".
[-- Attachment #1.2: Type: text/html, Size: 840 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: LOG_WARN or LOG_WARNING?
From: leam hall @ 2016-10-04 14:58 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <5530071.2YUX2fhZks@x2>
[-- Attachment #1.1: Type: text/plain, Size: 670 bytes --]
Sort of a followup question. I'm surprised adding "audit.none" to the
"/var/log/messages" line of rsyslog.conf (RHEL 6) works. I didn't think
audit was a full "facility" in whatever rsyslog looks at. Am I more
confused than normal?
Thanks!
Leam
On Tue, Oct 4, 2016 at 10:36 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Tuesday, October 4, 2016 10:10:31 AM EDT leam hall wrote:
> > For /etc/audisp/plugins.d/syslog.conf, is "LOG_WARN" an accpeted arg, or
> > does it need to be "LOG_WARNING"?
>
> LOG_WARNING.
>
> https://fedorahosted.org/audit/browser/trunk/audisp/
> audispd-builtins.c#L279
>
> -Steve
>
--
Mind on a Mission <http://leamhall.blogspot.com/>
[-- Attachment #1.2: Type: text/html, Size: 1460 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: LOG_WARN or LOG_WARNING?
From: Steve Grubb @ 2016-10-04 14:36 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CACv9p5rp8fXr-QK=6szFOsGPdO_NbsSWyjF++3ZXjMu6qxTeAA@mail.gmail.com>
On Tuesday, October 4, 2016 10:10:31 AM EDT leam hall wrote:
> For /etc/audisp/plugins.d/syslog.conf, is "LOG_WARN" an accpeted arg, or
> does it need to be "LOG_WARNING"?
LOG_WARNING.
https://fedorahosted.org/audit/browser/trunk/audisp/audispd-builtins.c#L279
-Steve
^ permalink raw reply
* Re: LOG_WARN or LOG_WARNING?
From: leam hall @ 2016-10-04 14:31 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CAEkAO+xHaToTosNTR6LptaYNwzCAGccCFp9FDaNsoiOy8bn40w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 425 bytes --]
Ryan, thanks!
On Tue, Oct 4, 2016 at 10:29 AM, Ryan Sawhill <rsawhill@redhat.com> wrote:
> On Tue, Oct 4, 2016 at 10:10 AM, leam hall <leamhall@gmail.com> wrote:
>
>> For /etc/audisp/plugins.d/syslog.conf, is "LOG_WARN" an accpeted arg, or
>> does it need to be "LOG_WARNING"?
>>
>
> You must use real facility names as documented in syslog(3), so:
> LOG_WARNING.
>
--
Mind on a Mission <http://leamhall.blogspot.com/>
[-- Attachment #1.2: Type: text/html, Size: 1274 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: LOG_WARN or LOG_WARNING?
From: Ryan Sawhill @ 2016-10-04 14:29 UTC (permalink / raw)
To: leam hall; +Cc: linux-audit
In-Reply-To: <CACv9p5rp8fXr-QK=6szFOsGPdO_NbsSWyjF++3ZXjMu6qxTeAA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 264 bytes --]
On Tue, Oct 4, 2016 at 10:10 AM, leam hall <leamhall@gmail.com> wrote:
> For /etc/audisp/plugins.d/syslog.conf, is "LOG_WARN" an accpeted arg, or
> does it need to be "LOG_WARNING"?
>
You must use real facility names as documented in syslog(3), so:
LOG_WARNING.
[-- Attachment #1.2: Type: text/html, Size: 630 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: commands in hex vs ASCII
From: Kevin Brown @ 2016-10-04 14:13 UTC (permalink / raw)
To: William Roberts; +Cc: linux-audit@redhat.com
In-Reply-To: <CAFftDdqQ-BBJXuC5_ZJcKO7_=oJkHttyBjbBNLS7cHdPWm5rDA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2028 bytes --]
Thanks for the responses so far
On Tuesday, October 4, 2016, William Roberts <bill.c.roberts@gmail.com>
wrote:
> You don't always need local access, I look at a lot of logs from systems I
> don't
> have access too, and I just decode them using python. I use the snippet
> from here to do it:
> http://stackoverflow.com/questions/9641440/convert-
> from-ascii-string-encoded-in-hex-to-plain-ascii
>
> It might not be ideal, I have simple needs. IIUC, ausearch also takes
> input from stdin, so you
> could cat raw log data you collected and use it on the other machine.
> I have some vague
> recollection of doing this years ago for Android, and it all worked as
> advertised.
>
>
>
> On Tue, Oct 4, 2016 at 10:00 AM, Steve Grubb <sgrubb@redhat.com
> <javascript:;>> wrote:
> > Hello,
> >
> > On Tuesday, October 4, 2016 9:46:32 AM EDT Kevin Brown wrote:
> >> Is there an option within auditd to set whether commands are stored as
> hex
> >> vs ASCII?
> >
> > No.
> >
> >> With the prevalence of SIEM these days, seems easier to keep the
> commands
> >> as ASCII and not presume a person needs to have access to a local
> system to
> >> run ausearch.
> >>
> >> Have gone through the documentation but didn't see an answer.
> >
> > This is a design decision from way back around 2005. The problem is that
> a
> > user can control certain things. If they want to evade detection or
> throw off
> > naive analysis, then the can do log injection attacks by using spaces,
> legal
> > field names, and carriage returns in fields controlled by the user.
> Simple
> > parsers will be tricked.
> >
> > There is some work currently going on wrt formatting output differently.
> In a
> > way I'd rather see some plugins created using libauparse that presents
> the
> > information to the siem in a format that it won't naively parse.
> >
> > -Steve
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com <javascript:;>
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>
> --
> Respectfully,
>
> William C Roberts
>
[-- Attachment #1.2: Type: text/html, Size: 2869 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: commands in hex vs ASCII
From: William Roberts @ 2016-10-04 14:11 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com, Kevin Brown
In-Reply-To: <3787073.SJSe6RgXKO@x2>
You don't always need local access, I look at a lot of logs from systems I don't
have access too, and I just decode them using python. I use the snippet
from here to do it:
http://stackoverflow.com/questions/9641440/convert-from-ascii-string-encoded-in-hex-to-plain-ascii
It might not be ideal, I have simple needs. IIUC, ausearch also takes
input from stdin, so you
could cat raw log data you collected and use it on the other machine.
I have some vague
recollection of doing this years ago for Android, and it all worked as
advertised.
On Tue, Oct 4, 2016 at 10:00 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> Hello,
>
> On Tuesday, October 4, 2016 9:46:32 AM EDT Kevin Brown wrote:
>> Is there an option within auditd to set whether commands are stored as hex
>> vs ASCII?
>
> No.
>
>> With the prevalence of SIEM these days, seems easier to keep the commands
>> as ASCII and not presume a person needs to have access to a local system to
>> run ausearch.
>>
>> Have gone through the documentation but didn't see an answer.
>
> This is a design decision from way back around 2005. The problem is that a
> user can control certain things. If they want to evade detection or throw off
> naive analysis, then the can do log injection attacks by using spaces, legal
> field names, and carriage returns in fields controlled by the user. Simple
> parsers will be tricked.
>
> There is some work currently going on wrt formatting output differently. In a
> way I'd rather see some plugins created using libauparse that presents the
> information to the siem in a format that it won't naively parse.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
Respectfully,
William C Roberts
^ permalink raw reply
* LOG_WARN or LOG_WARNING?
From: leam hall @ 2016-10-04 14:10 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 177 bytes --]
For /etc/audisp/plugins.d/syslog.conf, is "LOG_WARN" an accpeted arg, or
does it need to be "LOG_WARNING"?
Thanks!
Leam
--
Mind on a Mission <http://leamhall.blogspot.com/>
[-- Attachment #1.2: Type: text/html, Size: 375 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: commands in hex vs ASCII
From: Steve Grubb @ 2016-10-04 14:00 UTC (permalink / raw)
To: linux-audit; +Cc: Kevin Brown
In-Reply-To: <CABSg6BybAjhM+QZURYN3=B=f2Qn_+BGQKtn0b0PDZFJN0fBUyg@mail.gmail.com>
Hello,
On Tuesday, October 4, 2016 9:46:32 AM EDT Kevin Brown wrote:
> Is there an option within auditd to set whether commands are stored as hex
> vs ASCII?
No.
> With the prevalence of SIEM these days, seems easier to keep the commands
> as ASCII and not presume a person needs to have access to a local system to
> run ausearch.
>
> Have gone through the documentation but didn't see an answer.
This is a design decision from way back around 2005. The problem is that a
user can control certain things. If they want to evade detection or throw off
naive analysis, then the can do log injection attacks by using spaces, legal
field names, and carriage returns in fields controlled by the user. Simple
parsers will be tricked.
There is some work currently going on wrt formatting output differently. In a
way I'd rather see some plugins created using libauparse that presents the
information to the siem in a format that it won't naively parse.
-Steve
^ permalink raw reply
* commands in hex vs ASCII
From: Kevin Brown @ 2016-10-04 13:46 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 329 bytes --]
Hello,
Is there an option within auditd to set whether commands are stored as hex
vs ASCII?
With the prevalence of SIEM these days, seems easier to keep the commands
as ASCII and not presume a person needs to have access to a local system to
run ausearch.
Have gone through the documentation but didn't see an answer.
Thanks
[-- Attachment #1.2: Type: text/html, Size: 451 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Problem running auditd on Raspberry Pi (fedora-server-24)
From: C.y @ 2016-10-04 3:35 UTC (permalink / raw)
To: Steve Grubb, linux-audit
In-Reply-To: <737765219.ABlm5ovxsy@x2>
[-- Attachment #1.1: Type: text/plain, Size: 7098 bytes --]
On Tue, Oct 4, 2016 at 4:06 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Sunday, October 2, 2016 11:00:16 AM EDT C.y wrote:
> > On Sun, Oct 2, 2016 at 12:20 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > On Saturday, October 1, 2016 5:47:47 PM EDT C.y wrote:
> > > > Hi all,
> > > >
> > > >
> > > > I have fedora-server-24 installed on my raspberry-pi-3, following the
> > > > guide https://fedoraproject.org/wiki/Raspberry_Pi.
> > > >
> > > > Once I get my raspberry pi boot up, there were error mentioning that
> > > > "audit not support not in kernel", which I believed were then
> resolved after I
> > > > rebuild my kernel.
> > > >
> > > > However, I got stuck when I tried to add rule using `auditctl`
> command
> > > > as below:
> > > > `# auditctl -w /etc/passwd -p wa -k passwd_changes`
> > > > Error sending add rule data request (Invalid argument)
> > >
> > > Hmm. I wonder if 'ausyscall open' gives you syscalls.
> >
> > `# ausyscall open` returns as below. So I suppose the answer is
> > yes?(correct me if I'm wrong)
> > open 5
> > mq_open 274
> > openat 322
> > perf_event_open 364
> > open_by_handle_at 371
>
> This means user space is doing the right thing. I am thinking this sounds
> like
> a kernel issue.
>
> Have you tried a few other simple commands?
>
> auditctl -e 1
> auditctl -s
> auditctl -always,exit -F arch=b64 -S open
>
> -Steve
`# auditctl -e 1` returns:
enabled 1
failure 1
pid 293
rate_limit 0
backlog_limit 64
lost 11
backlog 0
backlog_wait_time 6000
`# auditctl -s` returns:
enabled 1
failure 1
pid 293
rate_limit 0
backlog_limit 64
lost 11
backlog 0
backlog_wait_time 6000
`# auditctl -a always,exit -F arch=b64 -S open` returns:
arch elf mapping not found
`# auditctl -a always,exit -S open` returns:
Error sending add rule data request (Invalid argument)
I also noticed that auditd is having difficulty in parsing
`/etc/auditd/auditd.rules`
on the booting stage,
`# journalctl -u auditd.service --this-boot` returns:
-- Logs begin at Fri 2016-02-12 00:28:01 CST, end at Tue 2016-10-04
10:53:05 CST. --
Feb 12 00:28:06 raspi3.lab systemd[1]: Starting Security Auditing Service...
Feb 12 00:28:06 raspi3.lab auditd[287]: Started dispatcher: /sbin/audispd
pid: 301
Feb 12 00:28:06 raspi3.lab audispd[301]: priority_boost_parser called with:
4
Feb 12 00:28:06 raspi3.lab augenrules[288]: /sbin/augenrules: No change
Feb 12 00:28:06 raspi3.lab audispd[301]: max_restarts_parser called with: 10
Feb 12 00:28:06 raspi3.lab augenrules[288]: Error sending add rule data
request (Invalid argument)
Feb 12 00:28:06 raspi3.lab augenrules[288]: There was an error in line 5 of
/etc/audit/audit.rules
Feb 12 00:28:06 raspi3.lab augenrules[288]: No rules
Feb 12 00:28:06 raspi3.lab systemd[1]: Started Security Auditing Service.
Feb 12 00:28:06 raspi3.lab auditd[287]: Init complete, auditd 2.5.2
listening for events (startup state
while `# cat /etc/audit/rules.d` returns:
-----
## This file is automatically generated from /etc/audit/rules.d
-D
-a task,never
-----
p/s: On the log above, RaspberryPi is showing the wrong time due to a
reboot,
the time will be corrected once the chronyd start functioning.
Regards,
CHING YI.
> > > > I tried to search for solution but it lead me to a bug that were
> already
> > > > been solved like years ago. Can anyone tell me if I am in the right
> way
> > > > of getting auditd works on raspberry pi? Were the problem I've faced
> were
> > > > already a known issue?
> > > >
> > > > Below are my system information and some logs/details when I tried to
> > > > diagnosis the problem and thanks a lot for your help in advance!
> > > >
> > > > `# uname -a`
> > > > Linux raspi3.lab 4.4.23-v7+ #2 SMP Sat Oct 1 15:24:41 CST 2016 armv7l
> > > > armv7l armv7l GNU/Linux
> > >
> > > I also wonder if we have a mismatch here. Is that armv seventy one or
> armv
> > > seven-el? Its coded in audit as seventy one.
> >
> > It's 7-el.
> > `# uname -a | grep 7l` (7-el) returns
> > Linux raspi3.lab 4.4.23-v7+ #2 SMP Sat Oct 1 15:24:41 CST 2016 armv7l
> > armv7l armv7l GNU/Linux
> >
> >
> > Sincerly,
> > CHING YI.
> >
> > > -Steve
> > >
> > > > `# modprobe configs ; gunzip -dc /proc/config.gz | grep AUDIT`
> > > > CONFIG_AUDIT=y
> > > > CONFIG_NETFILTER_XT_TARGET_AUDIT=m
> > > > CONFIG_AUDIT_GENERIC=y
> > > > # CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
> > > >
> > > > `# systemctl status auditd.service`
> > > > ● auditd.service - Security Auditing Service
> > > >
> > > > Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled;
> > > > vendor preset: enabled)
> > > >
> > > > Active: active (running) since Fri 2016-02-12 00:28:07 CST; 7
> months
> > > > 19 days ago
> > > >
> > > > Process: 1553 ExecReload=/bin/kill -HUP $MAINPID (code=exited,
> > > > status=0/SUCCESS)
> > > >
> > > > Process: 279 ExecStartPost=/sbin/augenrules --load (code=exited,
> > > > status=1/FAILURE)
> > > > Main PID: 278 (auditd)
> > > > CGroup: /system.slice/auditd.service
> > > > └─278 /sbin/auditd -n
> > > >
> > > > Oct 01 16:36:53 raspi3.lab auditd[278]: audit(1475311013.356:8458)
> > > > op=reconfigure state=changed auid=4294967295 pid=-1 subj=?
> res=success
> > > > Oct 01 16:36:53 raspi3.lab systemd[1]: Reloaded Security Auditing
> > > > Service.
> > > > Oct 01 16:37:28 raspi3.lab systemd[1]: Reloading Security Auditing
> > > > Service.
> > > > Oct 01 16:37:28 raspi3.lab auditd[278]: config change requested by
> > > > pid=-1
> > > > auid=4294967295 subj=?
> > > > Oct 01 16:37:28 raspi3.lab auditd[278]: audit(1475311048.046:257)
> > > > op=reconfigure state=changed auid=4294967295 pid=-1 subj=?
> res=success
> > > > Oct 01 16:37:28 raspi3.lab systemd[1]: Reloaded Security Auditing
> > > > Service.
> > > > Oct 01 16:38:18 raspi3.lab systemd[1]: Reloading Security Auditing
> > > > Service.
> > > > Oct 01 16:38:18 raspi3.lab auditd[278]: config change requested by
> > > > pid=-1
> > > > auid=4294967295 subj=?
> > > > Oct 01 16:38:18 raspi3.lab auditd[278]: audit(1475311098.716:2108)
> > > > op=reconfigure state=changed auid=4294967295 pid=-1 subj=?
> res=success
> > > > Oct 01 16:38:18 raspi3.lab systemd[1]: Reloaded Security Auditing
> > > > Service.
> > > >
> > > > While my `/var/log/audit/audit.log` was full with lines of
> > > > "SERVICE_START" & "SERVICE_STOP":
> > > > type=SERVICE_START msg=audit(1475313700.696:276): pid=1 uid=0
> > > > auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher
> > > > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
> > > > terminal=? res=success'
> > > > type=SERVICE_STOP msg=audit(1475313710.836:277): pid=1 uid=0
> > > > auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher
> > > > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
> > > > terminal=? res=success'
> > > >
> > > >
> > > > Sincerly,
> > > > CHING YI.
>
[-- Attachment #1.2: Type: text/html, Size: 9932 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [GIT PULL] Audit patches for v4.9
From: Paul Moore @ 2016-10-03 22:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-audit, linux-kernel
Hi Linus,
Another relatively small pull request for v4.9 with just two patches. The
patch from Richard updates the list of features we support and report back to
userspace; this should of been sent earlier with the rest of the v4.8 patches
but it got lost in my inbox. The second patch fixes a problem reported by our
Android friends where we weren't very consistent in recording PIDs.
Please merge these patches for v4.9.
Thanks,
-Paul
---
The following changes since commit 523d939ef98fd712632d93a5a2b588e477a7565e:
Linux 4.7 (2016-07-24 12:23:50 -0700)
are available in the git repository at:
git://git.infradead.org/users/pcmoore/audit stable-4.9
for you to fetch changes up to 7ff89ac608d9e856cae6fa651553fa0709bf9c50:
audit: add exclude filter extension to feature bitmap
(2016-09-29 13:12:09 -0400)
----------------------------------------------------------------
Paul Moore (1):
audit: consistently record PIDs with task_tgid_nr()
Richard Guy Briggs (1):
audit: add exclude filter extension to feature bitmap
include/uapi/linux/audit.h | 4 +++-
kernel/audit.c | 8 +++++++-
kernel/auditsc.c | 12 ++++++------
security/lsm_audit.c | 4 ++--
4 files changed, 18 insertions(+), 10 deletions(-)
--
paul moore
security @ redhat
^ permalink raw reply
* Re: ausearch checkpoint question
From: LC Bruzenak @ 2016-10-03 19:14 UTC (permalink / raw)
To: burn; +Cc: linux-audit@redhat.com
In-Reply-To: <1475188452.29460.49.camel@swtf.swtf.dyndns.org>
[-- Attachment #1.1: Type: text/plain, Size: 517 bytes --]
On 09/29/2016 04:34 PM, Burn Alting wrote:
> Lenny,
>
> I typically use
>
> TZ=UTC ausearch -i --input-logs \
> --checkpoint <somepath>/auditd_checkpoint.txt
>
> but I also set auditd.conf to have 9 x 32MB log files so the checkpoint
> code only scans the more recent files.
OK; thanks Burn. I store 20 x 100MB files; I need that many for my purposes.
I'll be testing it again under controlled conditions; seems like what I
need in one instance.
--
LC (Lenny) Bruzenak
lenny@magitekltd.com
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3805 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Problem running auditd on Raspberry Pi (fedora-server-24)
From: C.y @ 2016-10-02 7:14 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <2370484.LVpzHB65Xr@x2>
[-- Attachment #1.1: Type: text/plain, Size: 5820 bytes --]
On Sun, Oct 2, 2016 at 12:20 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Saturday, October 1, 2016 5:47:47 PM EDT C.y wrote:
> > Hi all,
> >
> >
> > I have fedora-server-24 installed on my raspberry-pi-3, following the
> guide
> > https://fedoraproject.org/wiki/Raspberry_Pi.
> >
> > Once I get my raspberry pi boot up, there were error mentioning that
> "audit
> > support not in kernel", which I believed were then resolved after I
> rebuild
> > my kernel.
> >
> > However, I got stuck when I tried to add rule using `auditctl` command as
> > below:
> > `# auditctl -w /etc/passwd -p wa -k passwd_changes`
> > Error sending add rule data request (Invalid argument)
>
> Hmm. I wonder if 'ausyscall open' gives you syscalls.
`# ausyscall open` returns as below. So I suppose the answer is
yes?(correct me if I'm wrong)
open 5
mq_open 274
openat 322
perf_event_open 364
open_by_handle_at 371
>
> > I tried to search for solution but it lead me to a bug that were already
> > been solved like years ago. Can anyone tell me if I am in the right way
> of
> > getting auditd works on raspberry pi? Were the problem I've faced were
> > already a known issue?
> >
> > Below are my system information and some logs/details when I tried to
> > diagnosis the problem and thanks a lot for your help in advance!
> >
> > `# uname -a`
> > Linux raspi3.lab 4.4.23-v7+ #2 SMP Sat Oct 1 15:24:41 CST 2016 armv7l
> > armv7l armv7l GNU/Linux
>
> I also wonder if we have a mismatch here. Is that armv seventy one or armv
> seven-el? Its coded in audit as seventy one.
It's 7-el.
`# uname -a | grep 7l` (7-el) returns
Linux raspi3.lab 4.4.23-v7+ #2 SMP Sat Oct 1 15:24:41 CST 2016 armv7l
armv7l armv7l GNU/Linux
Sincerly,
CHING YI.
Sincerly,
CHING YI.
On Sun, Oct 2, 2016 at 12:20 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Saturday, October 1, 2016 5:47:47 PM EDT C.y wrote:
> > Hi all,
> >
> >
> > I have fedora-server-24 installed on my raspberry-pi-3, following the
> guide
> > https://fedoraproject.org/wiki/Raspberry_Pi.
> >
> > Once I get my raspberry pi boot up, there were error mentioning that
> "audit
> > support not in kernel", which I believed were then resolved after I
> rebuild
> > my kernel.
> >
> > However, I got stuck when I tried to add rule using `auditctl` command as
> > below:
> > `# auditctl -w /etc/passwd -p wa -k passwd_changes`
> > Error sending add rule data request (Invalid argument)
>
> Hmm. I wonder if 'ausyscall open' gives you syscalls.
>
> > I tried to search for solution but it lead me to a bug that were already
> > been solved like years ago. Can anyone tell me if I am in the right way
> of
> > getting auditd works on raspberry pi? Were the problem I've faced were
> > already a known issue?
> >
> > Below are my system information and some logs/details when I tried to
> > diagnosis the problem and thanks a lot for your help in advance!
> >
> > `# uname -a`
> > Linux raspi3.lab 4.4.23-v7+ #2 SMP Sat Oct 1 15:24:41 CST 2016 armv7l
> > armv7l armv7l GNU/Linux
>
> I also wonder if we have a mismatch here. Is that armv seventy one or armv
> seven-el? Its coded in audit as seventy one.
>
> -Steve
>
> > `# modprobe configs ; gunzip -dc /proc/config.gz | grep AUDIT`
> > CONFIG_AUDIT=y
> > CONFIG_NETFILTER_XT_TARGET_AUDIT=m
> > CONFIG_AUDIT_GENERIC=y
> > # CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
> >
> > `# systemctl status auditd.service`
> > ● auditd.service - Security Auditing Service
> > Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled;
> vendor
> > preset: enabled)
> > Active: active (running) since Fri 2016-02-12 00:28:07 CST; 7 months
> 19
> > days ago
> > Process: 1553 ExecReload=/bin/kill -HUP $MAINPID (code=exited,
> > status=0/SUCCESS)
> > Process: 279 ExecStartPost=/sbin/augenrules --load (code=exited,
> > status=1/FAILURE)
> > Main PID: 278 (auditd)
> > CGroup: /system.slice/auditd.service
> > └─278 /sbin/auditd -n
> >
> > Oct 01 16:36:53 raspi3.lab auditd[278]: audit(1475311013.356:8458)
> > op=reconfigure state=changed auid=4294967295 pid=-1 subj=? res=success
> > Oct 01 16:36:53 raspi3.lab systemd[1]: Reloaded Security Auditing
> Service.
> > Oct 01 16:37:28 raspi3.lab systemd[1]: Reloading Security Auditing
> Service.
> > Oct 01 16:37:28 raspi3.lab auditd[278]: config change requested by pid=-1
> > auid=4294967295 subj=?
> > Oct 01 16:37:28 raspi3.lab auditd[278]: audit(1475311048.046:257)
> > op=reconfigure state=changed auid=4294967295 pid=-1 subj=? res=success
> > Oct 01 16:37:28 raspi3.lab systemd[1]: Reloaded Security Auditing
> Service.
> > Oct 01 16:38:18 raspi3.lab systemd[1]: Reloading Security Auditing
> Service.
> > Oct 01 16:38:18 raspi3.lab auditd[278]: config change requested by pid=-1
> > auid=4294967295 subj=?
> > Oct 01 16:38:18 raspi3.lab auditd[278]: audit(1475311098.716:2108)
> > op=reconfigure state=changed auid=4294967295 pid=-1 subj=? res=success
> > Oct 01 16:38:18 raspi3.lab systemd[1]: Reloaded Security Auditing
> Service.
> >
> > While my `/var/log/audit/audit.log` was full with lines of
> "SERVICE_START"
> > & "SERVICE_STOP"
> > type=SERVICE_START msg=audit(1475313700.696:276): pid=1 uid=0
> > auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher
> > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
> terminal=?
> > res=success'
> > type=SERVICE_STOP msg=audit(1475313710.836:277): pid=1 uid=0
> > auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher
> > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
> terminal=?
> > res=success'
> >
> >
> > Sincerly,
> > CHING YI.
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 8239 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH] audit: Use timespec64 to represent audit timestamps
From: Deepa Dinamani @ 2016-10-01 23:43 UTC (permalink / raw)
To: linux-kernel
Cc: Paul Moore, arnd, y2038, Eric Paris, Richard Guy Briggs,
linux-audit
struct timespec is not y2038 safe.
Audit timestamps are recorded in string format into
an audit buffer for a given context.
These mark the entry timestamps for the syscalls.
Use y2038 safe struct timespec64 to represent the times.
The log strings can handle this transition as strings can
hold upto 1024 characters.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Paul Moore <paul@paul-moore.com>
Acked-by: Richard Guy Briggs <rgb@redhat.com>
Cc: Eric Paris <eparis@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Richard Guy Briggs <rgb@redhat.com>
Cc: linux-audit@redhat.com
---
include/linux/audit.h | 4 ++--
kernel/audit.c | 10 +++++-----
kernel/audit.h | 2 +-
kernel/auditsc.c | 6 +++---
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 9d4443f..e51782b 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -332,7 +332,7 @@ static inline void audit_ptrace(struct task_struct *t)
/* Private API (for audit.c only) */
extern unsigned int audit_serial(void);
extern int auditsc_get_stamp(struct audit_context *ctx,
- struct timespec *t, unsigned int *serial);
+ struct timespec64 *t, unsigned int *serial);
extern int audit_set_loginuid(kuid_t loginuid);
static inline kuid_t audit_get_loginuid(struct task_struct *tsk)
@@ -490,7 +490,7 @@ static inline void __audit_seccomp(unsigned long syscall, long signr, int code)
static inline void audit_seccomp(unsigned long syscall, long signr, int code)
{ }
static inline int auditsc_get_stamp(struct audit_context *ctx,
- struct timespec *t, unsigned int *serial)
+ struct timespec64 *t, unsigned int *serial)
{
return 0;
}
diff --git a/kernel/audit.c b/kernel/audit.c
index a8a91bd..b03b6c7 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1325,10 +1325,10 @@ unsigned int audit_serial(void)
}
static inline void audit_get_stamp(struct audit_context *ctx,
- struct timespec *t, unsigned int *serial)
+ struct timespec64 *t, unsigned int *serial)
{
if (!ctx || !auditsc_get_stamp(ctx, t, serial)) {
- *t = CURRENT_TIME;
+ ktime_get_real_ts64(t);
*serial = audit_serial();
}
}
@@ -1370,7 +1370,7 @@ struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask,
int type)
{
struct audit_buffer *ab = NULL;
- struct timespec t;
+ struct timespec64 t;
unsigned int uninitialized_var(serial);
int reserve = 5; /* Allow atomic callers to go up to five
entries over the normal backlog limit */
@@ -1422,8 +1422,8 @@ struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask,
audit_get_stamp(ab->ctx, &t, &serial);
- audit_log_format(ab, "audit(%lu.%03lu:%u): ",
- t.tv_sec, t.tv_nsec/1000000, serial);
+ audit_log_format(ab, "audit(%llu.%03lu:%u): ",
+ (unsigned long long)t.tv_sec, t.tv_nsec/1000000, serial);
return ab;
}
diff --git a/kernel/audit.h b/kernel/audit.h
index 431444c..55d1ca2 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -112,7 +112,7 @@ struct audit_context {
enum audit_state state, current_state;
unsigned int serial; /* serial number for record */
int major; /* syscall number */
- struct timespec ctime; /* time of syscall entry */
+ struct timespec64 ctime; /* time of syscall entry */
unsigned long argv[4]; /* syscall arguments */
long return_code;/* syscall return code */
u64 prio;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 5abf1dc..8dc7fe9 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1522,7 +1522,7 @@ void __audit_syscall_entry(int major, unsigned long a1, unsigned long a2,
return;
context->serial = 0;
- context->ctime = CURRENT_TIME;
+ ktime_get_real_ts64(&context->ctime);
context->in_syscall = 1;
context->current_state = state;
context->ppid = 0;
@@ -1931,13 +1931,13 @@ EXPORT_SYMBOL_GPL(__audit_inode_child);
/**
* auditsc_get_stamp - get local copies of audit_context values
* @ctx: audit_context for the task
- * @t: timespec to store time recorded in the audit_context
+ * @t: timespec64 to store time recorded in the audit_context
* @serial: serial value that is recorded in the audit_context
*
* Also sets the context as auditable.
*/
int auditsc_get_stamp(struct audit_context *ctx,
- struct timespec *t, unsigned int *serial)
+ struct timespec64 *t, unsigned int *serial)
{
if (!ctx->in_syscall)
return 0;
--
2.7.4
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply related
* Re: Problem running auditd on Raspberry Pi (fedora-server-24)
From: Steve Grubb @ 2016-10-01 16:20 UTC (permalink / raw)
To: linux-audit; +Cc: C.y
In-Reply-To: <CABYhOsz3ChDrGafEp5aRiO7rsf-a40PO24o9jaFOeV3wLiPQrg@mail.gmail.com>
On Saturday, October 1, 2016 5:47:47 PM EDT C.y wrote:
> Hi all,
>
>
> I have fedora-server-24 installed on my raspberry-pi-3, following the guide
> https://fedoraproject.org/wiki/Raspberry_Pi.
>
> Once I get my raspberry pi boot up, there were error mentioning that "audit
> support not in kernel", which I believed were then resolved after I rebuild
> my kernel.
>
> However, I got stuck when I tried to add rule using `auditctl` command as
> below:
> `# auditctl -w /etc/passwd -p wa -k passwd_changes`
> Error sending add rule data request (Invalid argument)
Hmm. I wonder if 'ausyscall open' gives you syscalls.
> I tried to search for solution but it lead me to a bug that were already
> been solved like years ago. Can anyone tell me if I am in the right way of
> getting auditd works on raspberry pi? Were the problem I've faced were
> already a known issue?
>
> Below are my system information and some logs/details when I tried to
> diagnosis the problem and thanks a lot for your help in advance!
>
> `# uname -a`
> Linux raspi3.lab 4.4.23-v7+ #2 SMP Sat Oct 1 15:24:41 CST 2016 armv7l
> armv7l armv7l GNU/Linux
I also wonder if we have a mismatch here. Is that armv seventy one or armv
seven-el? Its coded in audit as seventy one.
-Steve
> `# modprobe configs ; gunzip -dc /proc/config.gz | grep AUDIT`
> CONFIG_AUDIT=y
> CONFIG_NETFILTER_XT_TARGET_AUDIT=m
> CONFIG_AUDIT_GENERIC=y
> # CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
>
> `# systemctl status auditd.service`
> ● auditd.service - Security Auditing Service
> Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor
> preset: enabled)
> Active: active (running) since Fri 2016-02-12 00:28:07 CST; 7 months 19
> days ago
> Process: 1553 ExecReload=/bin/kill -HUP $MAINPID (code=exited,
> status=0/SUCCESS)
> Process: 279 ExecStartPost=/sbin/augenrules --load (code=exited,
> status=1/FAILURE)
> Main PID: 278 (auditd)
> CGroup: /system.slice/auditd.service
> └─278 /sbin/auditd -n
>
> Oct 01 16:36:53 raspi3.lab auditd[278]: audit(1475311013.356:8458)
> op=reconfigure state=changed auid=4294967295 pid=-1 subj=? res=success
> Oct 01 16:36:53 raspi3.lab systemd[1]: Reloaded Security Auditing Service.
> Oct 01 16:37:28 raspi3.lab systemd[1]: Reloading Security Auditing Service.
> Oct 01 16:37:28 raspi3.lab auditd[278]: config change requested by pid=-1
> auid=4294967295 subj=?
> Oct 01 16:37:28 raspi3.lab auditd[278]: audit(1475311048.046:257)
> op=reconfigure state=changed auid=4294967295 pid=-1 subj=? res=success
> Oct 01 16:37:28 raspi3.lab systemd[1]: Reloaded Security Auditing Service.
> Oct 01 16:38:18 raspi3.lab systemd[1]: Reloading Security Auditing Service.
> Oct 01 16:38:18 raspi3.lab auditd[278]: config change requested by pid=-1
> auid=4294967295 subj=?
> Oct 01 16:38:18 raspi3.lab auditd[278]: audit(1475311098.716:2108)
> op=reconfigure state=changed auid=4294967295 pid=-1 subj=? res=success
> Oct 01 16:38:18 raspi3.lab systemd[1]: Reloaded Security Auditing Service.
>
> While my `/var/log/audit/audit.log` was full with lines of "SERVICE_START"
> & "SERVICE_STOP"
> type=SERVICE_START msg=audit(1475313700.696:276): pid=1 uid=0
> auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher
> comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> res=success'
> type=SERVICE_STOP msg=audit(1475313710.836:277): pid=1 uid=0
> auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher
> comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> res=success'
>
>
> Sincerly,
> CHING YI.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Problem running auditd on Raspberry Pi (fedora-server-24)
From: C.y @ 2016-10-01 9:47 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 3292 bytes --]
Hi all,
I have fedora-server-24 installed on my raspberry-pi-3, following the guide
https://fedoraproject.org/wiki/Raspberry_Pi.
Once I get my raspberry pi boot up, there were error mentioning that "audit
support not in kernel", which I believed were then resolved after I rebuild
my kernel.
However, I got stuck when I tried to add rule using `auditctl` command as
below:
`# auditctl -w /etc/passwd -p wa -k passwd_changes`
Error sending add rule data request (Invalid argument)
I tried to search for solution but it lead me to a bug that were already
been solved like years ago. Can anyone tell me if I am in the right way of
getting auditd works on raspberry pi? Were the problem I've faced were
already a known issue?
Below are my system information and some logs/details when I tried to
diagnosis the problem and thanks a lot for your help in advance!
`# uname -a`
Linux raspi3.lab 4.4.23-v7+ #2 SMP Sat Oct 1 15:24:41 CST 2016 armv7l
armv7l armv7l GNU/Linux
`# modprobe configs ; gunzip -dc /proc/config.gz | grep AUDIT`
CONFIG_AUDIT=y
CONFIG_NETFILTER_XT_TARGET_AUDIT=m
CONFIG_AUDIT_GENERIC=y
# CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
`# systemctl status auditd.service`
● auditd.service - Security Auditing Service
Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor
preset: enabled)
Active: active (running) since Fri 2016-02-12 00:28:07 CST; 7 months 19
days ago
Process: 1553 ExecReload=/bin/kill -HUP $MAINPID (code=exited,
status=0/SUCCESS)
Process: 279 ExecStartPost=/sbin/augenrules --load (code=exited,
status=1/FAILURE)
Main PID: 278 (auditd)
CGroup: /system.slice/auditd.service
└─278 /sbin/auditd -n
Oct 01 16:36:53 raspi3.lab auditd[278]: audit(1475311013.356:8458)
op=reconfigure state=changed auid=4294967295 pid=-1 subj=? res=success
Oct 01 16:36:53 raspi3.lab systemd[1]: Reloaded Security Auditing Service.
Oct 01 16:37:28 raspi3.lab systemd[1]: Reloading Security Auditing Service.
Oct 01 16:37:28 raspi3.lab auditd[278]: config change requested by pid=-1
auid=4294967295 subj=?
Oct 01 16:37:28 raspi3.lab auditd[278]: audit(1475311048.046:257)
op=reconfigure state=changed auid=4294967295 pid=-1 subj=? res=success
Oct 01 16:37:28 raspi3.lab systemd[1]: Reloaded Security Auditing Service.
Oct 01 16:38:18 raspi3.lab systemd[1]: Reloading Security Auditing Service.
Oct 01 16:38:18 raspi3.lab auditd[278]: config change requested by pid=-1
auid=4294967295 subj=?
Oct 01 16:38:18 raspi3.lab auditd[278]: audit(1475311098.716:2108)
op=reconfigure state=changed auid=4294967295 pid=-1 subj=? res=success
Oct 01 16:38:18 raspi3.lab systemd[1]: Reloaded Security Auditing Service.
While my `/var/log/audit/audit.log` was full with lines of "SERVICE_START"
& "SERVICE_STOP"
type=SERVICE_START msg=audit(1475313700.696:276): pid=1 uid=0
auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
type=SERVICE_STOP msg=audit(1475313710.836:277): pid=1 uid=0
auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
Sincerly,
CHING YI.
[-- Attachment #1.2: Type: text/html, Size: 3852 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: The default file for krb5_key_file is missing from the auditd.conf(5) manual
From: Steve Grubb @ 2016-09-30 12:50 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <642023E9-D9DD-40AA-B4A0-15301F25FA70@FreeBSD.org>
On Sunday, August 21, 2016 9:00:31 PM EDT Mateusz Piotrowski wrote:
> Hello,
>
> See this line[1]. It lacks the name of the default file.
>
> As I don't know what the default file is I cannot submit a patch.
> Hopefully, someone else can fix this file.
I forgot to reply but this was fixed in the latest release. Looks like a copy
and paste hit the wrong line. Thanks for pointing this out.
-Steve
^ permalink raw reply
* Re: ausearch checkpoint question
From: Burn Alting @ 2016-09-29 22:34 UTC (permalink / raw)
To: LC Bruzenak; +Cc: linux-audit@redhat.com
In-Reply-To: <57ED6BBC.7030503@magitekltd.com>
Lenny,
I typically use
TZ=UTC ausearch -i --input-logs \
--checkpoint <somepath>/auditd_checkpoint.txt
but I also set auditd.conf to have 9 x 32MB log files so the checkpoint
code only scans the more recent files.
On Thu, 2016-09-29 at 12:30 -0700, LC Bruzenak wrote:
> I'm using the 2.4.5-3 audit rpm set and I tried using the ausearch
> "checkpoint" option a couple weeks ago.
> This was on a moderately busy system (judging by my own
> systems/experience) generating say 300-400MB of data/day.
>
> I tried the checkpoint option in a 5-minute cron job, and I noticed that
> in comparison to the "-ts recent" option, it took far longer to complete.
> The "recent" option result was less than a second, whereas the
> checkpoint version took ~20 seconds every 5 minutes.
>
> It's possible there were other factors at play; e.g. it was used on a
> mls-policy machine, and although I saw no AVCs, it's possible there were
> some access issues I didn't have time to investigate.
> On my intended application, I'll be on a standard targeted-policy
> machine so this won't be a potential factor.
>
> I need to test this again, as I'm considering using the ausearch
> checkpoint capability for some new requirements, I was wondering if
> perhaps there were any timing results done or if there are any tips and
> tricks to getting the most out of it. Also - the man page section
> describing this is a little confusing to me so if anyone has a script
> segment that would be very helpful.
>
> Thanks in advance,
> LCB
>
^ permalink raw reply
* ausearch checkpoint question
From: LC Bruzenak @ 2016-09-29 19:30 UTC (permalink / raw)
To: linux-audit@redhat.com
I'm using the 2.4.5-3 audit rpm set and I tried using the ausearch
"checkpoint" option a couple weeks ago.
This was on a moderately busy system (judging by my own
systems/experience) generating say 300-400MB of data/day.
I tried the checkpoint option in a 5-minute cron job, and I noticed that
in comparison to the "-ts recent" option, it took far longer to complete.
The "recent" option result was less than a second, whereas the
checkpoint version took ~20 seconds every 5 minutes.
It's possible there were other factors at play; e.g. it was used on a
mls-policy machine, and although I saw no AVCs, it's possible there were
some access issues I didn't have time to investigate.
On my intended application, I'll be on a standard targeted-policy
machine so this won't be a potential factor.
I need to test this again, as I'm considering using the ausearch
checkpoint capability for some new requirements, I was wondering if
perhaps there were any timing results done or if there are any tips and
tricks to getting the most out of it. Also - the man page section
describing this is a little confusing to me so if anyone has a script
segment that would be very helpful.
Thanks in advance,
LCB
--
LC Bruzenak
magitekltd.com
^ permalink raw reply
* Re: [PATCH] audit: add exclude filter extension to feature bitmap
From: Paul Moore @ 2016-09-29 17:37 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit, linux-kernel
In-Reply-To: <d8623526ac43cfb6eaa3fec2887c904cd9829e7b.1471065260.git.rgb@redhat.com>
On Thu, Aug 18, 2016 at 12:05 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> Add to the audit feature bitmap to indicate availability of the
> extension of the exclude filter to include PID, UID, AUID, GID, SUBJ_*.
>
> RFE: add additional fields for use in audit filter exclude rules
> https://github.com/linux-audit/audit-kernel/issues/5
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> include/uapi/linux/audit.h | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
Somehow this fell through the cracks - merged into the audit next branch.
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index d820aa9..76c5e7e 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -327,9 +327,11 @@ enum {
> #define AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT 0x00000001
> #define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME 0x00000002
> #define AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH 0x00000004
> +#define AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND 0x00000008
> #define AUDIT_FEATURE_BITMAP_ALL (AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT | \
> AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME | \
> - AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH)
> + AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH | \
> + AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND)
>
> /* deprecated: AUDIT_VERSION_* */
> #define AUDIT_VERSION_LATEST AUDIT_FEATURE_BITMAP_ALL
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: Possible bug while setting syscall="all"
From: Steve Grubb @ 2016-09-28 13:05 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CAHikZs55WRQfCTCwtABdO-5A2M8nMgMqx=udWsanN_CreiKVbg@mail.gmail.com>
On Tuesday, September 27, 2016 6:35:28 PM EDT Nathan Brown wrote:
> I am trying to fully understand the ruledata struct. I've got most of it
> figured out but I can't find a reason for the final 32 bits (last index) of
> mask to not be flipped on when selecting all syscalls. In general it
> appears that the final 32 bits are never used.
>
> https://github.com/linux-audit/audit-userspace/blob/f588248775b4f8180b846bbc
> 1681bc54e07871ed/lib/libaudit.c#L907
Yes, this is a bug. Since there are nowhere near 2016 syscalls on any arch, it
hadn't really posed a problem. Fixed in svn commit 1397. Thanks for reporting
this.
-Steve
^ permalink raw reply
* Re: Question regarding ntpd
From: Sullivan, Daniel [CRI] @ 2016-09-28 1:45 UTC (permalink / raw)
To: Ryan Sawhill; +Cc: Jarsulic, Michael [CRI], linux-audit@redhat.com
In-Reply-To: <CAEkAO+xK=XTahKPK2WNkzriFOB3aQY0-U17AawqTa7=J+sjPnA@mail.gmail.com>
Thank you for chiming in, Ryan. I saw a thread describing a similar strategy out there, what was confusing me was really two fold;
1) the entries being generated every second (i.e. outside of whatever perceived polling interval was configured).
2) the entries apparently not having any meaningful information (if presumably some sort of adjustment was being made); perhaps the -i switch Steve provided will account for this.
I think the responses provided are enough to point me in the right direction. Thank you for your help.
Dan
On Sep 27, 2016, at 7:21 PM, Ryan Sawhill <rsawhill@redhat.com<mailto:rsawhill@redhat.com>> wrote:
To say the thing that Steve knows but didn't explicitly point out:
The "time-change" key is used in the standard STIG rules. If you can get the clearance from the powers-that-be in your org, note that the auditctl rule format allows you to exclude time-change events generated by something that you want to trust, e.g., ntpd. I wrote an article for this exact issue recently on the Red Hat Customer Portal. See: How to exclude specific users, groups, or services when using auditd to audit syscalls<https://access.redhat.com/solutions/2477471>
--
Linux-audit mailing list
Linux-audit@redhat.com<mailto:Linux-audit@redhat.com>
https://www.redhat.com/mailman/listinfo/linux-audit
********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please
notify the sender and destroy all copies of the transmittal.
Thank you
University of Chicago Medicine and Biological Sciences
********************************************************************************
^ permalink raw reply
* Re: Question regarding ntpd
From: Sullivan, Daniel [CRI] @ 2016-09-28 1:21 UTC (permalink / raw)
To: John Jasen; +Cc: linux-audit@redhat.com
In-Reply-To: <17354e80-2d5a-c268-dfe5-ae1d0e812eb7@gmail.com>
Actually this is kind of where my head was at too. It just didn’t look like there was any meaningful data in the audit entry (i.e. actual time values). I appreciate you taking the time to get back to me.
Also, FWIW I am completely new to auditd.
Dan
> On Sep 27, 2016, at 7:06 PM, John Jasen <jjasen@gmail.com> wrote:
>
> Reading this, my first thought was ntpd trying to adjust time drift on
> the client.
>
>
> On 09/27/2016 07:16 PM, Steve Grubb wrote:
>> On Tuesday, September 27, 2016 10:05:31 PM EDT Sullivan, Daniel [CRI] wrote:
>>> type=SYSCALL msg=audit(1475012495.972:5327): arch=c000003e syscall=159
>>> success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357
>>> auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38
>>> fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd"
>>> key="time-change”
>>>
>>> This is generating large amounts of log data.
>> Yep.
>>
>>> I am not an expert in auditd log analysis. Is this expected behavior?
>> Unfortunately for that syscall yes. Your best option is to not audit that
>> syscall.
>>
>>
>>> I am unsure of what the key time-change value of this log data is, and am
>>> wondering if this indicates some sort of misconfiguration or problem with
>>> ntpd.
>> Keys are used for reporting. You can run
>> aureport --start today --key --summary
>> to get an idea of what kinds of events you are getting. You can also use keys
>> with ausearch to extract events that trigger on a specific rule and then feed
>> that to aureport.
>>
>>
>>> From looking at the output of tcpdump it does not look like I am polling
>>> every second, so I am wondering why this activity is occurring. If anybody
>>> could advise on how to decipher these log entries I would appreciate it.
>>> Thank you for your help and advisement.
>> Well, using the -i option to ausearch gives more meaning:
>>
>> type=SYSCALL msg=audit(09/27/2016 17:41:35.972:5327) : arch=x86_64
>> syscall=adjtimex success=yes exit=0 a0=0x7ffd7498eb00 a1=0x861 a2=0x0 a3=0x1
>> items=0 ppid=1 pid=5357 auid=unset uid=ntp gid=ntp euid=ntp suid=ntp fsuid=ntp
>> egid=ntp sgid=ntp fsgid=ntp tty=(none) ses=unset comm=ntpd exe=/usr/sbin/ntpd
>> key=time-change
>>
>> But the syscall uses a single data struct and we have no visibility into that
>> so we cannot tell any more what its doing.
>>
>> The whole point of monitoring the time settings is that someone could tamper
>> with logs or cause something to appear like it occurred at a different time
>> than it really did. So, the idea is to collect this info "in case". But ntpd
>> overwhelms logs but chronyd might be marginally better. See bz
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=918127
>>
>> for some discussion.
>>
>> -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
********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please
notify the sender and destroy all copies of the transmittal.
Thank you
University of Chicago Medicine and Biological Sciences
********************************************************************************
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ 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