* Re: Regarding Auditing on RHEL 7.1
From: Steve Grubb @ 2016-02-25 19:52 UTC (permalink / raw)
To: linux-audit; +Cc: Sarthak Jain
In-Reply-To: <5078D98067B1B340BEE9F4F5FF71B8A733E824@BLRXMB02.microfocus.com>
On Wednesday, February 24, 2016 07:04:08 AM Sarthak Jain wrote:
> I am Sarthak Jain working in MicroFocus. I want your small help to clarify
> one of my doubt regarding the kernel auditing on RHEL 7.1. I hope you are
> the right person to contact. It will just 2 min (max :P) to go through the
> problem.
>
> Assumption: Ideally, if we change the configuration file (for ex-
> /etc/hosts), we should be getting audit events for it.
>
> Scenario: By default, the permissions for '/etc/hosts' is (rw-r-r--). If we
> modify this file, then audit events are coming as attached in file -
> 'file1.txt'.
>
> Problem: Let say if we change the permissions of the '/etc/hosts' to
> (rw-rw-rw), then audit system is not recording the "CONFIG_CHANGE" event at
> all.
That is because the audit configuration has not changed. Config change events
are specific to changes in the audit system itself. What you get on this is
syscall event with a path
If you want to get events on changing permissions on a file, then you would put
a rule like this:
-a always,exit -F path=/etc/hosts -F perms=a -F key=permission-change
After modifying the file with chmod, then run:
ausearch --start today -k permission-change
> I have attached the file - 'file2.txt' for your reference. Can you
> please clarify this ? Is it a kernel level bug?
No. Its doing what it should.
-Steve
^ permalink raw reply
* Re: Regarding Auditing on RHEL7.1
From: Paul Moore @ 2016-02-25 19:14 UTC (permalink / raw)
To: Sarthak Jain; +Cc: Richard Guy Briggs, linux-audit@redhat.com
In-Reply-To: <5078D98067B1B340BEE9F4F5FF71B8A733E923@BLRXMB02.microfocus.com>
On Wed, Feb 24, 2016 at 9:32 AM, Sarthak Jain
<Sarthak.Jain@microfocus.com> wrote:
> Hi,
>
> There has been one issue I am facing with auditing on RHEL 7.1. It is the same one as described here -
> https://www.redhat.com/archives/linux-audit/2015-January/msg00045.html
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1155208
>
> Can you please comment on this whether it has been fixed or not?
The issue has been fixed in upstream kernels as well as in RHEL-7.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: Audisp plugin and SELinux
From: Simon Sekidde @ 2016-02-24 15:53 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <21109581.qic73jJAcb@x2>
----- Original Message -----
> From: "Steve Grubb" <sgrubb@redhat.com>
> To: linux-audit@redhat.com
> Sent: Wednesday, February 24, 2016 10:02:25 AM
> Subject: Re: Audisp plugin and SELinux
>
> On Wednesday, February 24, 2016 04:40:13 PM Lev Stipakov wrote:
> > My audisp plugin has a file-based database in /var/lib/xxx directory. I
> > noticed that on systems with SELinux enabled plugin cannot read/write
> > that file.
> >
> > According to ps, plugin is run under audisp_t domain:
> >
> > -bash-4.1$ ps axZ | grep plugin
> > unconfined_u:system_r:audisp_t:s0 1845 ? S< 0:00 /usr/sbin/plugin 1
> >
> > Obviously I don't want to disable SELinux. What would be the recommended
> > way to allow plugin read/write file(s) under /var/run/xxx ?
>
If you label the dir as audisp_var_run_t then this should work nicely with SELinux
# semanage fcontext -a -t audisp_var_run_t /var/run/xxx
# restorecon -Rv /var/run/xxx
> The plugin should have its own policy. I don't think audisp_t should be
> broadened to allow things it shouldn't be doing. There are probably several
> people on this list that can give you advice on creating a policy.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
--
Simon Sekidde * Red Hat, Inc. * Westford, MA
gpg: 5848 958E 73BA 04D3 7C06 F096 1BA1 2DBF 94BC 377E
^ permalink raw reply
* Re: Audisp plugin and SELinux
From: Steve Grubb @ 2016-02-24 15:02 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <nakfcd$3ca$1@ger.gmane.org>
On Wednesday, February 24, 2016 04:40:13 PM Lev Stipakov wrote:
> My audisp plugin has a file-based database in /var/lib/xxx directory. I
> noticed that on systems with SELinux enabled plugin cannot read/write
> that file.
>
> According to ps, plugin is run under audisp_t domain:
>
> -bash-4.1$ ps axZ | grep plugin
> unconfined_u:system_r:audisp_t:s0 1845 ? S< 0:00 /usr/sbin/plugin 1
>
> Obviously I don't want to disable SELinux. What would be the recommended
> way to allow plugin read/write file(s) under /var/run/xxx ?
The plugin should have its own policy. I don't think audisp_t should be
broadened to allow things it shouldn't be doing. There are probably several
people on this list that can give you advice on creating a policy.
-Steve
^ permalink raw reply
* Audisp plugin and SELinux
From: Lev Stipakov @ 2016-02-24 14:40 UTC (permalink / raw)
To: linux-audit
Hello,
My audisp plugin has a file-based database in /var/lib/xxx directory. I
noticed that on systems with SELinux enabled plugin cannot read/write
that file.
According to ps, plugin is run under audisp_t domain:
-bash-4.1$ ps axZ | grep plugin
unconfined_u:system_r:audisp_t:s0 1845 ? S< 0:00 /usr/sbin/plugin 1
Obviously I don't want to disable SELinux. What would be the recommended
way to allow plugin read/write file(s) under /var/run/xxx ?
-Lev
^ permalink raw reply
* RE: Regarding Auditing on RHEL7.1
From: Sarthak Jain @ 2016-02-24 14:32 UTC (permalink / raw)
To: linux-audit@redhat.com; +Cc: Richard Guy Briggs
In-Reply-To: <20160224142907.GD20302@madcap2.tricolour.ca>
Hi,
There has been one issue I am facing with auditing on RHEL 7.1. It is the same one as described here -
https://www.redhat.com/archives/linux-audit/2015-January/msg00045.html
https://bugzilla.redhat.com/show_bug.cgi?id=1155208
Can you please comment on this whether it has been fixed or not?
Thanks
-----Original Message-----
From: Richard Guy Briggs [mailto:rgb@redhat.com]
Sent: Wednesday, February 24, 2016 7:59 PM
To: Sarthak Jain <Sarthak.Jain@microfocus.com>
Subject: Re: Regarding Auditing on RHEL7.1
On 16/02/24, Sarthak Jain wrote:
> Thank you Richard for replying and giving the proper contact. But you
> know in meanwhile, I came across this known bug -
>
> https://www.redhat.com/archives/linux-audit/2015-January/msg00045.html
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1155208
>
> Can you tell me whether it is under progress or it has been fixed?
You are welcome to ask on the list and Cc: me if you want my attention.
Please keep this public unless you have a service contract.
> Thanks
> -----Original Message-----
> From: Richard Guy Briggs [mailto:rgb@redhat.com]
> Sent: Wednesday, February 24, 2016 1:13 PM
> To: Sarthak Jain <Sarthak.Jain@microfocus.com>
> Subject: Re: Regarding Auditing on RHEL7.1
>
> On 16/02/24, Sarthak Jain wrote:
> > Hi Richard,
>
> Hi Sarthak,
>
> > I am Sarthak Jain working in MicroFocus. I want your small help to
> > clarify one of my doubt regarding the kernel auditing on RHEL 7.1. I
> > hope you are the right person to contact. It will just 2 min (max
> > :P) to go through the problem.
>
> For general audit-related questions, please use the linux-audit@redhat.com mailing list. For RHEL support questions, please contact your Red Hat service contract manager.
>
> > Assumption: Ideally, if we change the configuration file (for ex- /etc/hosts), we should be getting audit events for it.
> >
> > Scenario: By default, the permissions for '/etc/hosts' is (rw-r-r--). If we modify this file, then audit events are coming as attached in file - 'file1.txt'.
> >
> > Problem: Let say if we change the permissions of the '/etc/hosts' to (rw-rw-rw), then audit system is not recording the "CONFIG_CHANGE" event at all. I have attached the file - 'file2.txt' for your reference. Can you please clarify this ? Is it a kernel level bug?
> >
> > I would be greatly thankful to you if you could please comment on this.
> >
> > Thanks.
> >
> >
>
> > ----
> > time->Wed Feb 24 00:44:20 2016
> > type=CONFIG_CHANGE msg=audit(1456296260.392:3012733752): auid=0
> > ses=612921 op="updated rules" path="/etc/hosts" key=(null) list=4
> > res=1
> > ----
> > time->Wed Feb 24 00:44:20 2016
> > type=PATH msg=audit(1456296260.392:3012733753): item=3
> > name="/etc/hosts~" inode=133015 dev=fd:01 mode=0100700 ouid=0 ogid=0
> > rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=CREATE
> > type=PATH msg=audit(1456296260.392:3012733753): item=2
> > name="/etc/hosts" inode=133015 dev=fd:01 mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=DELETE type=PATH msg=audit(1456296260.392:3012733753): item=1 name="/etc/" inode=130309 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT type=PATH msg=audit(1456296260.392:3012733753): item=0 name="/etc/" inode=130309 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT type=CWD msg=audit(1456296260.392:3012733753): cwd="/root"
> > type=SYSCALL msg=audit(1456296260.392:3012733753): arch=c000003e
> > syscall=82 success=yes exit=0 a0=1d5c730 a1=1d82ab0
> > a2=fffffffffffffea0 a3=7fffcc152380 items=4 ppid=7009 pid=7575
> > auid=0
> > uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1
> > ses=612921 comm="vi" exe="/usr/bin/vi"
> > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > key=(null)
> > ----
> > time->Wed Feb 24 00:44:20 2016
> > type=CONFIG_CHANGE msg=audit(1456296260.393:3012733754): auid=0
> > ses=612921 op="updated rules" path="/etc/hosts" key=(null) list=4
> > res=1
> > ----
> > time->Wed Feb 24 00:44:20 2016
> > type=PATH msg=audit(1456296260.393:3012733755): item=1
> > name="/etc/hosts" inode=133022 dev=fd:01 mode=0100700 ouid=0 ogid=0
> > rdev=00:00 obj=unconfined_u:object_r:net_conf_t:s0 objtype=CREATE type=PATH msg=audit(1456296260.393:3012733755): item=0 name="/etc/" inode=130309 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT type=CWD msg=audit(1456296260.393:3012733755): cwd="/root"
> > type=SYSCALL msg=audit(1456296260.393:3012733755): arch=c000003e
> > syscall=2 success=yes exit=3 a0=1d5c730 a1=241 a2=1c0 a3=0 items=2
> > ppid=7009 pid=7575 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> > sgid=0 fsgid=0 tty=pts1 ses=612921 comm="vi" exe="/usr/bin/vi"
> > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > key=(null)
> > ----
> > time->Wed Feb 24 00:44:20 2016
> > type=PATH msg=audit(1456296260.413:3012733759): item=0
> > name="/etc/hosts" inode=133022 dev=fd:01 mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:net_conf_t:s0 objtype=NORMAL type=CWD msg=audit(1456296260.413:3012733759): cwd="/root"
> > type=SYSCALL msg=audit(1456296260.413:3012733759): arch=c000003e
> > syscall=188 success=yes exit=0 a0=1d5c730 a1=7fc4923b877e a2=1d81fd0
> > a3=20 items=1 ppid=7009 pid=7575 auid=0 uid=0 gid=0 euid=0 suid=0
> > fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=612921 comm="vi"
> > exe="/usr/bin/vi"
> > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > key=(null)
> > ----
> > time->Wed Feb 24 00:44:20 2016
> > type=PATH msg=audit(1456296260.413:3012733761): item=0
> > name="/etc/hosts" inode=133022 dev=fd:01 mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL type=CWD msg=audit(1456296260.413:3012733761): cwd="/root"
> > type=SYSCALL msg=audit(1456296260.413:3012733761): arch=c000003e
> > syscall=90 success=yes exit=0 a0=1d5c730 a1=81c0 a2=0 a3=20 items=1
> > ppid=7009 pid=7575 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> > sgid=0 fsgid=0 tty=pts1 ses=612921 comm="vi" exe="/usr/bin/vi"
> > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > key=(null)
> > ----
> > time->Wed Feb 24 00:44:20 2016
> > type=PATH msg=audit(1456296260.414:3012733762): item=0
> > name="/etc/hosts" inode=133022 dev=fd:01 mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL type=CWD msg=audit(1456296260.414:3012733762): cwd="/root"
> > type=SYSCALL msg=audit(1456296260.414:3012733762): arch=c000003e
> > syscall=188 success=yes exit=0 a0=1d5c730 a1=7fc491f71ddf a2=1d81c30
> > a3=1c items=1 ppid=7009 pid=7575 auid=0 uid=0 gid=0 euid=0 suid=0
> > fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=612921 comm="vi"
> > exe="/usr/bin/vi"
> > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > key=(null)
>
> > ----
> > time->Wed Feb 24 00:45:55 2016
> > type=PATH msg=audit(1456296355.292:3012759691): item=0
> > name="/etc/hosts~" inode=133015 dev=fd:01 mode=0100666 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL type=CWD msg=audit(1456296355.292:3012759691): cwd="/root"
> > type=SYSCALL msg=audit(1456296355.292:3012759691): arch=c000003e syscall=132 success=yes exit=0 a0=2245a70 a1=7fffdf2b4390 a2=2000 a3=7fffdf2b4050 items=1 ppid=7009 pid=7704 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=612921 comm="vi" exe="/usr/bin/vi" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="9980284E037547A8A9364B62ACB360C6"
> > ----
> > time->Wed Feb 24 00:45:55 2016
> > type=PATH msg=audit(1456296355.303:3012759696): item=0
> > name="/etc/hosts" inode=133022 dev=fd:01 mode=0100666 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL type=CWD msg=audit(1456296355.303:3012759696): cwd="/root"
> > type=SYSCALL msg=audit(1456296355.303:3012759696): arch=c000003e
> > syscall=90 success=yes exit=0 a0=221f730 a1=81b6 a2=0
> > a3=7fffdf2b4050
> > items=1 ppid=7009 pid=7704 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0
> > egid=0 sgid=0 fsgid=0 tty=pts1 ses=612921 comm="vi" exe="/usr/bin/vi"
> > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > key=(null)
>
>
> - 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
- 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
* Regarding Auditing on RHEL 7.1
From: Sarthak Jain @ 2016-02-24 7:04 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 882 bytes --]
Hi,
I am Sarthak Jain working in MicroFocus. I want your small help to clarify one of my doubt regarding the kernel auditing on RHEL 7.1. I hope you are the right person to contact. It will just 2 min (max :P) to go through the problem.
Assumption: Ideally, if we change the configuration file (for ex- /etc/hosts), we should be getting audit events for it.
Scenario: By default, the permissions for '/etc/hosts' is (rw-r-r--). If we modify this file, then audit events are coming as attached in file - 'file1.txt'.
Problem: Let say if we change the permissions of the '/etc/hosts' to (rw-rw-rw), then audit system is not recording the "CONFIG_CHANGE" event at all. I have attached the file - 'file2.txt' for your reference. Can you please clarify this ? Is it a kernel level bug?
I would be greatly thankful to you if you could please comment on this.
Thanks.
[-- Attachment #1.2: Type: text/html, Size: 3125 bytes --]
[-- Attachment #2: file1.txt --]
[-- Type: text/plain, Size: 4222 bytes --]
----
time->Wed Feb 24 00:44:20 2016
type=CONFIG_CHANGE msg=audit(1456296260.392:3012733752): auid=0 ses=612921 op="updated rules" path="/etc/hosts" key=(null) list=4 res=1
----
time->Wed Feb 24 00:44:20 2016
type=PATH msg=audit(1456296260.392:3012733753): item=3 name="/etc/hosts~" inode=133015 dev=fd:01 mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=CREATE
type=PATH msg=audit(1456296260.392:3012733753): item=2 name="/etc/hosts" inode=133015 dev=fd:01 mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=DELETE
type=PATH msg=audit(1456296260.392:3012733753): item=1 name="/etc/" inode=130309 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT
type=PATH msg=audit(1456296260.392:3012733753): item=0 name="/etc/" inode=130309 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT
type=CWD msg=audit(1456296260.392:3012733753): cwd="/root"
type=SYSCALL msg=audit(1456296260.392:3012733753): arch=c000003e syscall=82 success=yes exit=0 a0=1d5c730 a1=1d82ab0 a2=fffffffffffffea0 a3=7fffcc152380 items=4 ppid=7009 pid=7575 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=612921 comm="vi" exe="/usr/bin/vi" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
----
time->Wed Feb 24 00:44:20 2016
type=CONFIG_CHANGE msg=audit(1456296260.393:3012733754): auid=0 ses=612921 op="updated rules" path="/etc/hosts" key=(null) list=4 res=1
----
time->Wed Feb 24 00:44:20 2016
type=PATH msg=audit(1456296260.393:3012733755): item=1 name="/etc/hosts" inode=133022 dev=fd:01 mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:net_conf_t:s0 objtype=CREATE
type=PATH msg=audit(1456296260.393:3012733755): item=0 name="/etc/" inode=130309 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT
type=CWD msg=audit(1456296260.393:3012733755): cwd="/root"
type=SYSCALL msg=audit(1456296260.393:3012733755): arch=c000003e syscall=2 success=yes exit=3 a0=1d5c730 a1=241 a2=1c0 a3=0 items=2 ppid=7009 pid=7575 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=612921 comm="vi" exe="/usr/bin/vi" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
----
time->Wed Feb 24 00:44:20 2016
type=PATH msg=audit(1456296260.413:3012733759): item=0 name="/etc/hosts" inode=133022 dev=fd:01 mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:net_conf_t:s0 objtype=NORMAL
type=CWD msg=audit(1456296260.413:3012733759): cwd="/root"
type=SYSCALL msg=audit(1456296260.413:3012733759): arch=c000003e syscall=188 success=yes exit=0 a0=1d5c730 a1=7fc4923b877e a2=1d81fd0 a3=20 items=1 ppid=7009 pid=7575 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=612921 comm="vi" exe="/usr/bin/vi" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
----
time->Wed Feb 24 00:44:20 2016
type=PATH msg=audit(1456296260.413:3012733761): item=0 name="/etc/hosts" inode=133022 dev=fd:01 mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL
type=CWD msg=audit(1456296260.413:3012733761): cwd="/root"
type=SYSCALL msg=audit(1456296260.413:3012733761): arch=c000003e syscall=90 success=yes exit=0 a0=1d5c730 a1=81c0 a2=0 a3=20 items=1 ppid=7009 pid=7575 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=612921 comm="vi" exe="/usr/bin/vi" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
----
time->Wed Feb 24 00:44:20 2016
type=PATH msg=audit(1456296260.414:3012733762): item=0 name="/etc/hosts" inode=133022 dev=fd:01 mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL
type=CWD msg=audit(1456296260.414:3012733762): cwd="/root"
type=SYSCALL msg=audit(1456296260.414:3012733762): arch=c000003e syscall=188 success=yes exit=0 a0=1d5c730 a1=7fc491f71ddf a2=1d81c30 a3=1c items=1 ppid=7009 pid=7575 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=612921 comm="vi" exe="/usr/bin/vi" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
[-- Attachment #3: file2.txt --]
[-- Type: text/plain, Size: 1299 bytes --]
----
time->Wed Feb 24 00:45:55 2016
type=PATH msg=audit(1456296355.292:3012759691): item=0 name="/etc/hosts~" inode=133015 dev=fd:01 mode=0100666 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL
type=CWD msg=audit(1456296355.292:3012759691): cwd="/root"
type=SYSCALL msg=audit(1456296355.292:3012759691): arch=c000003e syscall=132 success=yes exit=0 a0=2245a70 a1=7fffdf2b4390 a2=2000 a3=7fffdf2b4050 items=1 ppid=7009 pid=7704 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=612921 comm="vi" exe="/usr/bin/vi" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="9980284E037547A8A9364B62ACB360C6"
----
time->Wed Feb 24 00:45:55 2016
type=PATH msg=audit(1456296355.303:3012759696): item=0 name="/etc/hosts" inode=133022 dev=fd:01 mode=0100666 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL
type=CWD msg=audit(1456296355.303:3012759696): cwd="/root"
type=SYSCALL msg=audit(1456296355.303:3012759696): arch=c000003e syscall=90 success=yes exit=0 a0=221f730 a1=81b6 a2=0 a3=7fffdf2b4050 items=1 ppid=7009 pid=7704 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=612921 comm="vi" exe="/usr/bin/vi" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
[-- Attachment #4: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: space_left_action syslog
From: Steve Grubb @ 2016-02-23 16:25 UTC (permalink / raw)
To: linux-audit; +Cc: Maupertuis Philippe
In-Reply-To: <3D2AB1326AB2974190FCE3F69401F790DB1EBF0C7D@FRVDX103.fr01.awl.atosorigin.net>
On Tuesday, February 23, 2016 11:54:21 AM Maupertuis Philippe wrote:
> The man page reads space_left_action : syslog means that it will issue a
> warning to syslog. Please tell me where can I find an example of such a
> message to look for it in the syslog ?
https://fedorahosted.org/audit/browser/trunk/src/auditd-event.c#L515
> Would the message be different for admin_space_left_action and
> disk_full_action ?
Yes for admin_space_left and disk full is here:
https://fedorahosted.org/audit/browser/trunk/src/auditd-event.c#L571
I suppose a distinction could be made between space_left and
admin_space_left messages, but if you get either it needs attention right
away.
> When audispd is configured to send audit events to syslog would these
> messages follow the same path.
Auditd sends them to syslog directly. Because these are not events, audispd
will never see them.
-Steve
> I would like to be able to separate these messages for an easy notice should
> something go wrong.
^ permalink raw reply
* space_left_action syslog
From: Maupertuis Philippe @ 2016-02-23 10:54 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 1759 bytes --]
Hi list,
The man page reads space_left_action : syslog means that it will issue a warning to syslog.
Please tell me where can I find an example of such a message to look for it in the syslog ?
Would the message be different for admin_space_left_action and disk_full_action ?
When audispd is configured to send audit events to syslog would these messages follow the same path.
I would like to be able to separate these messages for an easy notice should something go wrong.
Regards.
Philippe
________________________________
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.
[-- Attachment #1.2: Type: text/html, Size: 4195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH 2/2] vfs: don't always include audit-specific members of struct filename
From: Rasmus Villemoes @ 2016-02-16 22:49 UTC (permalink / raw)
To: Alexander Viro, Paul Moore, Eric Paris, Jeff Layton,
J. Bruce Fields
Cc: Rasmus Villemoes, linux-fsdevel, linux-kernel, linux-audit
In-Reply-To: <1455662966-7977-1-git-send-email-linux@rasmusvillemoes.dk>
The three members uptr, aname and refcnt are only used when
CONFIG_AUDITSYSCALL, a fact which is not obvious from the header file
or namei.c alone. So aside from eliminating a few useless instructions
in getname_flags and making EMBEDDED_NAME_MAX a little larger, this
patch also serves to document whoe the actual user of these members
is.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
fs/namei.c | 10 ++++------
include/linux/audit.h | 9 +++++++++
include/linux/fs.h | 2 ++
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index bd150fa799a2..21410db25814 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -185,7 +185,6 @@ getname_flags(const char __user *filename, int flags, int *empty)
}
}
- result->refcnt = 1;
/* The empty path is special. */
if (unlikely(!len)) {
if (empty)
@@ -196,8 +195,7 @@ getname_flags(const char __user *filename, int flags, int *empty)
}
}
- result->uptr = filename;
- result->aname = NULL;
+ audit_init_filename(result, filename);
audit_getname(result);
return result;
}
@@ -235,9 +233,7 @@ getname_kernel(const char * filename)
return ERR_PTR(-ENAMETOOLONG);
}
memcpy((char *)result->name, filename, len);
- result->uptr = NULL;
- result->aname = NULL;
- result->refcnt = 1;
+ audit_init_filename(result, NULL);
audit_getname(result);
return result;
@@ -245,10 +241,12 @@ getname_kernel(const char * filename)
void putname(struct filename *name)
{
+#ifdef CONFIG_AUDITSYSCALL
BUG_ON(name->refcnt <= 0);
if (--name->refcnt > 0)
return;
+#endif
if (name->name != name->iname) {
__putname(name->name);
diff --git a/include/linux/audit.h b/include/linux/audit.h
index b40ed5df5542..7d7143674d85 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -232,6 +232,12 @@ extern void __audit_syscall_entry(int major, unsigned long a0, unsigned long a1,
extern void __audit_syscall_exit(int ret_success, long ret_value);
extern struct filename *__audit_reusename(const __user char *uptr);
extern void __audit_getname(struct filename *name);
+static inline void audit_init_filename(struct filename *name, const __user char *uptr)
+{
+ name->refcnt = 1;
+ name->aname = NULL;
+ name->uptr = uptr;
+}
#define AUDIT_INODE_PARENT 1 /* dentry represents the parent */
#define AUDIT_INODE_HIDDEN 2 /* audit record should be hidden */
@@ -459,6 +465,9 @@ static inline struct filename *audit_reusename(const __user char *name)
}
static inline void audit_getname(struct filename *name)
{ }
+static inline void audit_init_filename(struct filename *name, const __user char *uptr)
+{ }
+
static inline void __audit_inode(struct filename *name,
const struct dentry *dentry,
unsigned int flags)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index d522e6391855..df769f738695 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2243,12 +2243,14 @@ static inline int break_layout(struct inode *inode, bool wait)
struct audit_names;
struct filename {
const char *name; /* pointer to actual string */
+#ifdef CONFIG_AUDITSYSCALL
const __user char *uptr; /* original userland pointer */
struct audit_names *aname;
union {
int refcnt;
long __padding;
};
+#endif
const char iname[];
};
--
2.1.4
^ permalink raw reply related
* Re: Running multiple audit service clients
From: Steve Grubb @ 2016-02-12 19:13 UTC (permalink / raw)
To: linux-audit; +Cc: Richard Guy Briggs, Max Timchenko
In-Reply-To: <CAF6gGuApsX4J3NFXxqwJ4VAm-eHiW1zpGvJCfFpuyNq7oC8y1w@mail.gmail.com>
On Thursday, February 11, 2016 03:19:27 PM Max Timchenko wrote:
> I have read the docs on audispd(8) - is it something auditd and the other
> client could use to enable multiple access? It sounds like audispd does
> support multiple clients, but I would guess all clients would have to use
> the audispd plugin interface instead of the usual kernel API.
Yes. This is intentional and has existed for about 10 years.
> What is missing from the documentation for me is the relationship between
> audispd and auditd - whether audispd is an optional component of auditd that
> can run concurrently
Yes. If you look in auditd.conf, you will see that there is a configuration
option, dispatcher, which allows you to select another consumer of audit
events. Normally the selection of /sbin/audispd is the best because it allows
"unlimited" multiplexing of the audit stream.
You can send events to syslog, setroubleshoot, and remotely log events in an
aggregator all at the same time.
> , or audispd is a replacement of auditd when configured
> (and then auditd cannot run on the same machine
> without running into the same multi-client issues).
No. The audispd man page says, "audispd is an audit event multiplexor. It has
to be started by the audit daemon in order to get events."
HTH...
-Steve
^ permalink raw reply
* Re: Audit log Fields
From: Steve Grubb @ 2016-02-12 19:04 UTC (permalink / raw)
To: linux-audit, burn; +Cc: Sowndarya K
In-Reply-To: <1455196014.28800.61.camel@swtf.swtf.dyndns.org>
On Friday, February 12, 2016 12:06:54 AM Burn Alting wrote:
> Steve,
>
> Perhaps we could update the above document to advise users what they
> should offer in such a proposal.
Good point. Usually they come to the list and say I am working on a daemon
that needs to write something to the audit log whenever this kind of thing
happens. How should I record it.
This leads to a better conversation because not everything is a candidate for
the audit logs. That doesn't mean it doesn't need to be recorded, it just
means it needs to go somewhere else.
For example, tcp_wrappers can reject connections. Should that go into audit
logs automatically? No way. Same with web application access control. These
are important enough to be logged, but they belong in an application log.
> Perhaps further, we could offer a generic solution on how one could
> define a 'non-public' field name. That is, a 'non-public' field is one
> which could not, via it's nomenclature, conflict with a current or
> future 'public' (aka published) field name. Such non-public fields could
> then be used by capability that only needs the audit source and audit
> consumer to be aware of the field.
That's a good point. I'm pretty sure 'private-' will never be used for a prefix
to any field. That said, if this is going into an existing event, we really
need to have a discussion about that. This affects all third party's that try
to make sense of the audit logs,
-Steve
^ permalink raw reply
* Re: Audit log Fields
From: Steve Grubb @ 2016-02-12 18:57 UTC (permalink / raw)
To: linux-audit; +Cc: Sowndarya K
In-Reply-To: <CAKc3OY1obXePLv5ac7B3g3EAm=XjZkDFPHDXaFU4q11UMj3NYw@mail.gmail.com>
On Thursday, February 11, 2016 06:07:56 PM Sowndarya K wrote:
> As of now there are so many proposed fields in the audit event log , if I
> wanted to one proposed field which is of not use as much ,which one can I
> chose for ?
The audit event known fields is kind of an agreement on what fields names shall
be and what goes in them. There is a larger context in that events of the same
type must have the same fields, in the same order, and using the same
representation. Otherwise no one can ever analyse events because nothing has
order.
So, what is it you are trying to do? That would be a more helpful question so
that we can give you a more rounded answer.
-Steve
^ permalink raw reply
* Re: Reserved fields in audit log structure
From: Steve Grubb @ 2016-02-12 18:54 UTC (permalink / raw)
To: linux-audit; +Cc: Sowndarya K
In-Reply-To: <CAKc3OY1c_VT5Wr==aunirdkrCSKB8VAemofG0JAXNRCAQR4_fA@mail.gmail.com>
On Thursday, February 11, 2016 11:42:27 AM Sowndarya K wrote:
> What are the reserved fields in audit log structure?
There are known fields that kind of mean reserved because we expect them to be
a certain way. Its documented here:
http://people.redhat.com/sgrubb/audit/audit-events.txt
and a test suite to verify events are searchable here:
http://people.redhat.com/sgrubb/audit/ausearch-test-0.5.tar.gz
And we need to continue work on the validation suite so that it can be used to
check events completely.
-Steve
^ permalink raw reply
* Re: Running multiple audit service clients
From: Steve Grubb @ 2016-02-12 18:50 UTC (permalink / raw)
To: linux-audit; +Cc: Max Timchenko
In-Reply-To: <CAF6gGuCK1QmU18QsHs0h0t3S6-gehQzXvyfJbNLj7QpRfL9VVQ@mail.gmail.com>
On Wednesday, February 10, 2016 04:28:26 PM Max Timchenko wrote:
> I have a situation where there are two audit clients on the same machine:
> one of them is auditd, and another one is an IDS client that uses the audit
> subsystem directly.
It should not be designed that way. For compliance purposes many people have
to save the audit logs. I have given several speeches on how to do this so
that everyone has a correct model to work from. The latest speech on audit+IDS
is here:
http://people.redhat.com/sgrubb/audit/audit_ids_2011.pdf
The main idea is that auditd has a builtin facility for sharing events,
auditspd. The IDS system can clip into it and get the event stream. If it
wants events as they come "off the wire" they should set the format option to
BINARY and they will get it exactly as it was handed to auditd. More typical
is to use STRING format so that they can use auparse to dissect the event for
processing.
> By looking at the source (
> http://lxr.free-electrons.com/source/kernel/audit.c?v=3.13#L787), I suspect
> that there might be no provision in the kernel for multiple audit subsystem
> userland daemons running in parallel (only one pid, only one netlink socket
> in the kernel). I could not find any documentation confirming or denying
> that.
There is not. Nor should there be. With the ease in which analysis programs
can get the audit stream, they should not have to resort to exclusive access.
For example, setroubleshooter plugin puts something in /etc/audisp/plugins.d/
so that it can see events in realtime. Its a good example of "doing it right".
> Has anyone tried that before? What would actually happen if two different
> audit clients tried to use the same interface to the audit subsystem in the
> kernel?
Last one wins.
-Steve
^ permalink raw reply
* Re: Running multiple audit service clients
From: Richard Guy Briggs @ 2016-02-12 4:39 UTC (permalink / raw)
To: Max Timchenko; +Cc: linux-audit
In-Reply-To: <CAF6gGuApsX4J3NFXxqwJ4VAm-eHiW1zpGvJCfFpuyNq7oC8y1w@mail.gmail.com>
On 16/02/11, Max Timchenko wrote:
> On Wed, Feb 10, 2016 at 9:30 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
>
> > On 16/02/10, Max Timchenko wrote:
> > > Has anyone tried that before? What would actually happen if two different
> > > audit clients tried to use the same interface to the audit subsystem in
> > the
> > > kernel?
> >
> > With recent changes upstream, the second would be denied with -EEXIST.
> >
> > Before that, the older one would be starved out. And versions even
> > older might actually have the newer one orphaned in the very occasional
> > race where the older one shuts down after the second one starts.
> >
> > To quote Highlander, "There Can Be Only One".
>
> Thanks Richard and Paul for your quick responses. It's great to hear
> that support for containers is being worked on.
>
> I have read the docs on audispd(8) - is it something auditd and the
> other client could use to enable multiple access? It sounds like
> audispd does support multiple clients, but I would guess all clients
> would have to use the audispd plugin interface instead of the usual
> kernel API.
>
> What is missing from the documentation for me is the relationship
> between audispd and auditd - whether audispd is an optional component
> of auditd that can run concurrently, or audispd is a replacement of
> auditd when configured (and then auditd cannot run on the same machine
> without running into the same multi-client issues).
I will defer to Steve Grubb on this quesition as the userspace tools are
his domain of expertise.
> Yours,
> --
> Max
- 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: Running multiple audit service clients
From: Max Timchenko @ 2016-02-11 20:19 UTC (permalink / raw)
To: Richard Guy Briggs, Paul Moore; +Cc: linux-audit
In-Reply-To: <20160211023015.GI22138@madcap2.tricolour.ca>
[-- Attachment #1.1: Type: text/plain, Size: 1369 bytes --]
On Wed, Feb 10, 2016 at 9:30 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 16/02/10, Max Timchenko wrote:
> > Has anyone tried that before? What would actually happen if two different
> > audit clients tried to use the same interface to the audit subsystem in
> the
> > kernel?
>
> With recent changes upstream, the second would be denied with -EEXIST.
>
> Before that, the older one would be starved out. And versions even
> older might actually have the newer one orphaned in the very occasional
> race where the older one shuts down after the second one starts.
>
> To quote Highlander, "There Can Be Only One".
>
Thanks Richard and Paul for your quick responses. It's great to hear that
support for
containers is being worked on.
I have read the docs on audispd(8) - is it something auditd and the other
client could use to enable multiple access? It sounds like audispd does
support
multiple clients, but I would guess all clients would have to use the
audispd plugin
interface instead of the usual kernel API.
What is missing from the documentation for me is the relationship between
audispd
and auditd - whether audispd is an optional component of auditd that can
run
concurrently, or audispd is a replacement of auditd when configured
(and then auditd cannot run on the same machine
without running into the same multi-client issues).
Yours,
--
Max
[-- Attachment #1.2: Type: text/html, Size: 2289 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Audit log Fields
From: Burn Alting @ 2016-02-11 13:06 UTC (permalink / raw)
To: Sowndarya K; +Cc: Linux-audit
In-Reply-To: <CAKc3OY1obXePLv5ac7B3g3EAm=XjZkDFPHDXaFU4q11UMj3NYw@mail.gmail.com>
Sowndarya,
Are you are asking how do you propose another public field name to be
added to the list in
https://people.redhat.com/sgrubb/audit/audit-events.txt ?
If so, I'd suggest you provide
a. Proposed field name
b. Description of it's content.
c. Describe how it's going to be used.
The list can then make comment and/or provide advice.
Steve,
Perhaps we could update the above document to advise users what they
should offer in such a proposal.
Perhaps further, we could offer a generic solution on how one could
define a 'non-public' field name. That is, a 'non-public' field is one
which could not, via it's nomenclature, conflict with a current or
future 'public' (aka published) field name. Such non-public fields could
then be used by capability that only needs the audit source and audit
consumer to be aware of the field.
Hopefully I am not reading too much into the original request.
Regards
On Thu, 2016-02-11 at 18:07 +0530, Sowndarya K wrote:
> As of now there are so many proposed fields in the audit event log ,
> if I wanted to one proposed field which is of not use as much ,which
> one can I chose for ?
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Audit log Fields
From: Sowndarya K @ 2016-02-11 12:37 UTC (permalink / raw)
To: Linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 160 bytes --]
As of now there are so many proposed fields in the audit event log , if I
wanted to one proposed field which is of not use as much ,which one can I
chose for ?
[-- Attachment #1.2: Type: text/html, Size: 184 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Reserved fields in audit log structure
From: Burn Alting @ 2016-02-11 11:55 UTC (permalink / raw)
To: Sowndarya K; +Cc: Linux-audit
In-Reply-To: <CAKc3OY1c_VT5Wr==aunirdkrCSKB8VAemofG0JAXNRCAQR4_fA@mail.gmail.com>
Hi,
Are asking about the existing known field names found in the following
https://people.redhat.com/sgrubb/audit/audit-events.txt
or something else?
On Thu, 2016-02-11 at 11:42 +0530, Sowndarya K wrote:
> What are the reserved fields in audit log structure?
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Running multiple audit service clients
From: Paul Moore @ 2016-02-11 8:16 UTC (permalink / raw)
To: Max Timchenko, Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20160211023015.GI22138@madcap2.tricolour.ca>
On Wed, Feb 10, 2016 at 9:30 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> There is also planning to be done to allow one auditd per user
> namespace to support containers, but we aren't there yet.
To add to that, we will also provide better support for containers
with a single auditd instance (the microservices case) by providing
better marking of audit records to help indicate which namespace set
(what the kernel would consider a container) generated the audit
event.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Reserved fields in audit log structure
From: Sowndarya K @ 2016-02-11 6:12 UTC (permalink / raw)
To: Linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 53 bytes --]
What are the reserved fields in audit log structure?
[-- Attachment #1.2: Type: text/html, Size: 78 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Running multiple audit service clients
From: Richard Guy Briggs @ 2016-02-11 2:30 UTC (permalink / raw)
To: Max Timchenko; +Cc: linux-audit
In-Reply-To: <CAF6gGuCK1QmU18QsHs0h0t3S6-gehQzXvyfJbNLj7QpRfL9VVQ@mail.gmail.com>
On 16/02/10, Max Timchenko wrote:
> Dear all,
>
> I have a situation where there are two audit clients on the same machine:
> one of them is auditd, and another one is an IDS client that uses the audit
> subsystem directly. By looking at the source (
> http://lxr.free-electrons.com/source/kernel/audit.c?v=3.13#L787), I suspect
> that there might be no provision in the kernel for multiple audit subsystem
> userland daemons running in parallel (only one pid, only one netlink socket
> in the kernel). I could not find any documentation confirming or denying
> that.
>
> Has anyone tried that before? What would actually happen if two different
> audit clients tried to use the same interface to the audit subsystem in the
> kernel?
With recent changes upstream, the second would be denied with -EEXIST.
Before that, the older one would be starved out. And versions even
older might actually have the newer one orphaned in the very occasional
race where the older one shuts down after the second one starts.
To quote Highlander, "There Can Be Only One".
There is also planning to be done to allow one auditd per user
namespace to support containers, but we aren't there yet.
> Max
- 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
* Running multiple audit service clients
From: Max Timchenko @ 2016-02-10 21:28 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 690 bytes --]
Dear all,
I have a situation where there are two audit clients on the same machine:
one of them is auditd, and another one is an IDS client that uses the audit
subsystem directly. By looking at the source (
http://lxr.free-electrons.com/source/kernel/audit.c?v=3.13#L787), I suspect
that there might be no provision in the kernel for multiple audit subsystem
userland daemons running in parallel (only one pid, only one netlink socket
in the kernel). I could not find any documentation confirming or denying
that.
Has anyone tried that before? What would actually happen if two different
audit clients tried to use the same interface to the audit subsystem in the
kernel?
Yours,
--
Max
[-- Attachment #1.2: Type: text/html, Size: 968 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] audit: Fix typo in comment
From: Paul Moore @ 2016-02-08 16:29 UTC (permalink / raw)
To: Wei Yuan; +Cc: eparis, linux-audit, linux-kernel
In-Reply-To: <1454744387-29608-1-git-send-email-weiyuan.wei@huawei.com>
On Saturday, February 06, 2016 03:39:47 PM Wei Yuan wrote:
> Signed-off-by: Weiyuan <weiyuan.wei@huawei.com>
> ---
> kernel/audit_watch.c | 2 +-
> kernel/auditfilter.c | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
Applied.
> diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
> index 9f194aa..3cf1c59 100644
> --- a/kernel/audit_watch.c
> +++ b/kernel/audit_watch.c
> @@ -185,7 +185,7 @@ static struct audit_watch *audit_init_watch(char *path)
> return watch;
> }
>
> -/* Translate a watch string to kernel respresentation. */
> +/* Translate a watch string to kernel representation. */
> int audit_to_watch(struct audit_krule *krule, char *path, int len, u32 op)
> {
> struct audit_watch *watch;
> diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
> index b8ff9e1..94ca7b1 100644
> --- a/kernel/auditfilter.c
> +++ b/kernel/auditfilter.c
> @@ -158,7 +158,7 @@ char *audit_unpack_string(void **bufp, size_t *remain,
> size_t len) return str;
> }
>
> -/* Translate an inode field to kernel respresentation. */
> +/* Translate an inode field to kernel representation. */
> static inline int audit_to_inode(struct audit_krule *krule,
> struct audit_field *f)
> {
> @@ -415,7 +415,7 @@ static int audit_field_valid(struct audit_entry *entry,
> struct audit_field *f) return 0;
> }
>
> -/* Translate struct audit_rule_data to kernel's rule respresentation. */
> +/* Translate struct audit_rule_data to kernel's rule representation. */
> static struct audit_entry *audit_data_to_entry(struct audit_rule_data
> *data, size_t datasz)
> {
> @@ -593,7 +593,7 @@ static inline size_t audit_pack_string(void **bufp,
> const char *str) return len;
> }
>
> -/* Translate kernel rule respresentation to struct audit_rule_data. */
> +/* Translate kernel rule representation to struct audit_rule_data. */
> static struct audit_rule_data *audit_krule_to_data(struct audit_krule
> *krule) {
> struct audit_rule_data *data;
--
paul moore
www.paul-moore.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox