* 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
* Re: Linux-audit Digest, Vol 137, Issue 3
From: Richard Guy Briggs @ 2016-02-08 11:56 UTC (permalink / raw)
To: Sowndarya K; +Cc: linux-audit
In-Reply-To: <CAKc3OY34m+iZBKA4a9huiQir3TGE2mKcVnBonhNPzc6aqvrmkA@mail.gmail.com>
On 16/02/08, Sowndarya K wrote:
> How do *I* can get the complete code change of the following patch set
> https://www.redhat.com/archives/linux-audit/2013-October/msg00048.html ?
Go to the link under "references". They are all listed there.
That patch set is no longer relevant since auditd can now communicate
from any network namespace.
(Please fix the subject line back to the relevant subject when you reply
to a digest email.)
> On Thu, Feb 4, 2016 at 10:30 PM, <linux-audit-request@redhat.com> wrote:
> > Send Linux-audit mailing list submissions to
> > linux-audit@redhat.com
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://www.redhat.com/mailman/listinfo/linux-audit
> > or, via email, send a message with subject or body 'help' to
> > linux-audit-request@redhat.com
> >
> > You can reach the person managing the list at
> > linux-audit-owner@redhat.com
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Linux-audit digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: Regarding Auditd fails to start (Richard Guy Briggs)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Thu, 4 Feb 2016 05:15:57 -0500
> > From: Richard Guy Briggs <rgb@redhat.com>
> > To: Sowndarya K <sowndaryak18@gmail.com>
> > Cc: linux-audit@redhat.com
> > Subject: Re: Regarding Auditd fails to start
> > Message-ID: <20160204101557.GD27528@madcap2.tricolour.ca>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On 16/02/04, Sowndarya K wrote:
> > > Thanks for your valuable response Richard!!
> >
> > Better late than never! (Re-adding the mailing list for openness and
> > information sharing.)
> >
> > > Now what I am facing as a problem is when I run auditd inside two
> > different
> > > containers,the recent one which has started the auditd service is logging
> > > all the processes which are created in other containers as well.How do I
> > > take care of it in such a way that container specific process records
> > > should be logged at each respective containers .
> >
> > This should not be possible for the definition of container that
> > immediately comes to mind with any existing kernel I know of. How do
> > you define a container? In particular from my point of interest, which
> > namespaces are cloned? It should not be possible if the user or pid
> > namespace has been cloned since the kernel explicitly blocks these for
> > the time being. I suspect neither one has been cloned and you are
> > seeing symptoms of RHBZ #1253123 which allows more than one auditd to
> > exist in the initial namespaces. This has been addressed in Paul
> > Moore's upstream kernel audit git tree as 133e1e5 to prevent this from
> > happenning unless you have also run into RHBZ #1243308 that was a
> > netlink rhashtable issue which should already be fixed in upstream
> > kernels.
> >
> > > On Wed, Feb 3, 2016 at 9:31 PM, Richard Guy Briggs <rgb@redhat.com>
> > wrote:
> > > > On 16/02/03, Paul Moore wrote:
> > > > > On Wed, Feb 3, 2016 at 9:08 AM, Steve Grubb <sgrubb@redhat.com>
> > wrote:
> > > > > > On Wed, 3 Feb 2016 07:57:52 -0500
> > > > > > Paul Moore <paul@paul-moore.com> wrote:
> > > > > >> On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb@redhat.com>
> > wrote:
> > > > > >> > On Wed, 3 Feb 2016 15:34:09 +0530
> > > > > >> > Sowndarya K <sowndaryak18@gmail.com> wrote:
> > > > > >> >> I am running docker container without privileges and now
> > service
> > > > > >> >> auditd start fails to execute even I add capabilities to
> > docker.
> > > > > >> >> please try to help me as early as possible
> > > > > >> >
> > > > > >> > If auditd is being run inside a container, then it has problems
> > > > > >> > because the audit subsystem inside the kernel isn't container
> > > > > >> > aware/namespaced. I have recently made changes to auditd in svn
> > for
> > > > > >> > the next release which allows auditd to run as a log
> > _aggregator_
> > > > > >> > inside a container. This means it has no knowledge of events
> > coming
> > > > > >> > from within the container but can act as an aggregator for
> > systems
> > > > > >> > doing remote logging.
> > > > > >>
> > > > > >> To add some commentary to this: we are not going to namespace the
> > > > > >> audit subsystem like other subsystems, but making audit *aware* of
> > > > > >> namespaces is on the todo list.
> > > > > >
> > > > > > OK. Suppose I go out and rent a virtualized server with root
> > access for
> > > > > > my web site. Turns out the company that is leasing me time used
> > > > > > containers as their method of virtualizing. my web site runs fine
> > in a
> > > > > > container so no big deal. However, as a customer, I would want
> > access
> > > > > > to the logs for my container directly in the container. As a
> > matter of
> > > > > > fact, its a PCI-DSS requirement to have access to those logs.
> > > > > >
> > > > > > I really think the audit system _has to be_ namespaced, somehow,
> > for
> > > > > > compliance reasons.
> > > > >
> > > > > Having access to audit events generated inside a namespace (or set of
> > > > > namespaces to be more specific), and only generated inside a
> > namespace
> > > > > (or set of ...), does not require the audit subsystem to be
> > > > > namespaced; however, it does require the audit subsystem to recognize
> > > > > namespaces and associate them with events so that they can be tagged
> > > > > and routed accordingly. Based on previous conversations, I suspect
> > we
> > > > > have the same goals/ideas and are just using different terminology.
> > I
> > > > > wouldn't worry too much about it at this point as that work is still
> > > > > in the early stages.
> > > >
> > > > I'm late in the conversation, but "what Steve and Paul said". A number
> > > > of discussions have already happenned concerning this idea and the goal
> > > > is to have auditd be able to run pretty much seamlessly inside a
> > > > container without influencing or compromising the auditd running in the
> > > > parent namespace(s). From what we have discussed, it appears most
> > > > likely that auditd will be anchored one per user namespace.
> > > >
> > > > > paul moore
> > > >
> > > > - RGB
> >
> > - RGB
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* Re: Linux-audit Digest, Vol 137, Issue 3
From: Sowndarya K @ 2016-02-08 11:08 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <mailman.65.1454605206.24519.linux-audit@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 6253 bytes --]
How do *I* can get the complete code change of the following patch set
https://www.redhat.com/archives/linux-audit/2013-October/msg00048.html ?
On Thu, Feb 4, 2016 at 10:30 PM, <linux-audit-request@redhat.com> wrote:
> Send Linux-audit mailing list submissions to
> linux-audit@redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.redhat.com/mailman/listinfo/linux-audit
> or, via email, send a message with subject or body 'help' to
> linux-audit-request@redhat.com
>
> You can reach the person managing the list at
> linux-audit-owner@redhat.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linux-audit digest..."
>
>
> Today's Topics:
>
> 1. Re: Regarding Auditd fails to start (Richard Guy Briggs)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 4 Feb 2016 05:15:57 -0500
> From: Richard Guy Briggs <rgb@redhat.com>
> To: Sowndarya K <sowndaryak18@gmail.com>
> Cc: linux-audit@redhat.com
> Subject: Re: Regarding Auditd fails to start
> Message-ID: <20160204101557.GD27528@madcap2.tricolour.ca>
> Content-Type: text/plain; charset=us-ascii
>
> On 16/02/04, Sowndarya K wrote:
> > Thanks for your valuable response Richard!!
>
> Better late than never! (Re-adding the mailing list for openness and
> information sharing.)
>
> > Now what I am facing as a problem is when I run auditd inside two
> different
> > containers,the recent one which has started the auditd service is logging
> > all the processes which are created in other containers as well.How do I
> > take care of it in such a way that container specific process records
> > should be logged at each respective containers .
>
> This should not be possible for the definition of container that
> immediately comes to mind with any existing kernel I know of. How do
> you define a container? In particular from my point of interest, which
> namespaces are cloned? It should not be possible if the user or pid
> namespace has been cloned since the kernel explicitly blocks these for
> the time being. I suspect neither one has been cloned and you are
> seeing symptoms of RHBZ #1253123 which allows more than one auditd to
> exist in the initial namespaces. This has been addressed in Paul
> Moore's upstream kernel audit git tree as 133e1e5 to prevent this from
> happenning unless you have also run into RHBZ #1243308 that was a
> netlink rhashtable issue which should already be fixed in upstream
> kernels.
>
> > On Wed, Feb 3, 2016 at 9:31 PM, Richard Guy Briggs <rgb@redhat.com>
> wrote:
> > > On 16/02/03, Paul Moore wrote:
> > > > On Wed, Feb 3, 2016 at 9:08 AM, Steve Grubb <sgrubb@redhat.com>
> wrote:
> > > > > On Wed, 3 Feb 2016 07:57:52 -0500
> > > > > Paul Moore <paul@paul-moore.com> wrote:
> > > > >> On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb@redhat.com>
> wrote:
> > > > >> > On Wed, 3 Feb 2016 15:34:09 +0530
> > > > >> > Sowndarya K <sowndaryak18@gmail.com> wrote:
> > > > >> >> I am running docker container without privileges and now
> service
> > > > >> >> auditd start fails to execute even I add capabilities to
> docker.
> > > > >> >> please try to help me as early as possible
> > > > >> >
> > > > >> > If auditd is being run inside a container, then it has problems
> > > > >> > because the audit subsystem inside the kernel isn't container
> > > > >> > aware/namespaced. I have recently made changes to auditd in svn
> for
> > > > >> > the next release which allows auditd to run as a log
> _aggregator_
> > > > >> > inside a container. This means it has no knowledge of events
> coming
> > > > >> > from within the container but can act as an aggregator for
> systems
> > > > >> > doing remote logging.
> > > > >>
> > > > >> To add some commentary to this: we are not going to namespace the
> > > > >> audit subsystem like other subsystems, but making audit *aware* of
> > > > >> namespaces is on the todo list.
> > > > >
> > > > > OK. Suppose I go out and rent a virtualized server with root
> access for
> > > > > my web site. Turns out the company that is leasing me time used
> > > > > containers as their method of virtualizing. my web site runs fine
> in a
> > > > > container so no big deal. However, as a customer, I would want
> access
> > > > > to the logs for my container directly in the container. As a
> matter of
> > > > > fact, its a PCI-DSS requirement to have access to those logs.
> > > > >
> > > > > I really think the audit system _has to be_ namespaced, somehow,
> for
> > > > > compliance reasons.
> > > >
> > > > Having access to audit events generated inside a namespace (or set of
> > > > namespaces to be more specific), and only generated inside a
> namespace
> > > > (or set of ...), does not require the audit subsystem to be
> > > > namespaced; however, it does require the audit subsystem to recognize
> > > > namespaces and associate them with events so that they can be tagged
> > > > and routed accordingly. Based on previous conversations, I suspect
> we
> > > > have the same goals/ideas and are just using different terminology.
> I
> > > > wouldn't worry too much about it at this point as that work is still
> > > > in the early stages.
> > >
> > > I'm late in the conversation, but "what Steve and Paul said". A number
> > > of discussions have already happenned concerning this idea and the goal
> > > is to have auditd be able to run pretty much seamlessly inside a
> > > container without influencing or compromising the auditd running in the
> > > parent namespace(s). From what we have discussed, it appears most
> > > likely that auditd will be anchored one per user namespace.
> > >
> > > > paul moore
> > >
> > > - RGB
>
> - RGB
>
> --
> Richard Guy Briggs <rbriggs@redhat.com>
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating
> Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
>
>
>
> ------------------------------
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
> End of Linux-audit Digest, Vol 137, Issue 3
> *******************************************
>
[-- Attachment #1.2: Type: text/html, Size: 8744 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH] audit: Fix typo in comment
From: Wei Yuan @ 2016-02-06 7:39 UTC (permalink / raw)
To: paul, eparis; +Cc: linux-audit, linux-kernel
Signed-off-by: Weiyuan <weiyuan.wei@huawei.com>
---
kernel/audit_watch.c | 2 +-
kernel/auditfilter.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
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;
--
2.1.0
^ permalink raw reply related
* Re: Regarding Auditd fails to start
From: Richard Guy Briggs @ 2016-02-04 10:15 UTC (permalink / raw)
To: Sowndarya K; +Cc: linux-audit
In-Reply-To: <CAKc3OY1JUXH82o6G+W_Ue7zBBGe-dgGw3OEgTqn+iOwmFaWfsw@mail.gmail.com>
On 16/02/04, Sowndarya K wrote:
> Thanks for your valuable response Richard!!
Better late than never! (Re-adding the mailing list for openness and
information sharing.)
> Now what I am facing as a problem is when I run auditd inside two different
> containers,the recent one which has started the auditd service is logging
> all the processes which are created in other containers as well.How do I
> take care of it in such a way that container specific process records
> should be logged at each respective containers .
This should not be possible for the definition of container that
immediately comes to mind with any existing kernel I know of. How do
you define a container? In particular from my point of interest, which
namespaces are cloned? It should not be possible if the user or pid
namespace has been cloned since the kernel explicitly blocks these for
the time being. I suspect neither one has been cloned and you are
seeing symptoms of RHBZ #1253123 which allows more than one auditd to
exist in the initial namespaces. This has been addressed in Paul
Moore's upstream kernel audit git tree as 133e1e5 to prevent this from
happenning unless you have also run into RHBZ #1243308 that was a
netlink rhashtable issue which should already be fixed in upstream
kernels.
> On Wed, Feb 3, 2016 at 9:31 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 16/02/03, Paul Moore wrote:
> > > On Wed, Feb 3, 2016 at 9:08 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > > On Wed, 3 Feb 2016 07:57:52 -0500
> > > > Paul Moore <paul@paul-moore.com> wrote:
> > > >> On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > >> > On Wed, 3 Feb 2016 15:34:09 +0530
> > > >> > Sowndarya K <sowndaryak18@gmail.com> wrote:
> > > >> >> I am running docker container without privileges and now service
> > > >> >> auditd start fails to execute even I add capabilities to docker.
> > > >> >> please try to help me as early as possible
> > > >> >
> > > >> > If auditd is being run inside a container, then it has problems
> > > >> > because the audit subsystem inside the kernel isn't container
> > > >> > aware/namespaced. I have recently made changes to auditd in svn for
> > > >> > the next release which allows auditd to run as a log _aggregator_
> > > >> > inside a container. This means it has no knowledge of events coming
> > > >> > from within the container but can act as an aggregator for systems
> > > >> > doing remote logging.
> > > >>
> > > >> To add some commentary to this: we are not going to namespace the
> > > >> audit subsystem like other subsystems, but making audit *aware* of
> > > >> namespaces is on the todo list.
> > > >
> > > > OK. Suppose I go out and rent a virtualized server with root access for
> > > > my web site. Turns out the company that is leasing me time used
> > > > containers as their method of virtualizing. my web site runs fine in a
> > > > container so no big deal. However, as a customer, I would want access
> > > > to the logs for my container directly in the container. As a matter of
> > > > fact, its a PCI-DSS requirement to have access to those logs.
> > > >
> > > > I really think the audit system _has to be_ namespaced, somehow, for
> > > > compliance reasons.
> > >
> > > Having access to audit events generated inside a namespace (or set of
> > > namespaces to be more specific), and only generated inside a namespace
> > > (or set of ...), does not require the audit subsystem to be
> > > namespaced; however, it does require the audit subsystem to recognize
> > > namespaces and associate them with events so that they can be tagged
> > > and routed accordingly. Based on previous conversations, I suspect we
> > > have the same goals/ideas and are just using different terminology. I
> > > wouldn't worry too much about it at this point as that work is still
> > > in the early stages.
> >
> > I'm late in the conversation, but "what Steve and Paul said". A number
> > of discussions have already happenned concerning this idea and the goal
> > is to have auditd be able to run pretty much seamlessly inside a
> > container without influencing or compromising the auditd running in the
> > parent namespace(s). From what we have discussed, it appears most
> > likely that auditd will be anchored one per user namespace.
> >
> > > paul moore
> >
> > - RGB
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* Re: Regarding Auditd fails to start
From: Richard Guy Briggs @ 2016-02-03 16:01 UTC (permalink / raw)
To: Paul Moore; +Cc: Sowndarya K, Linux-audit
In-Reply-To: <CAHC9VhRu-usMcebuG0+wpF-viY9xbBTRV1G6XP90pit-D22xrg@mail.gmail.com>
On 16/02/03, Paul Moore wrote:
> On Wed, Feb 3, 2016 at 9:08 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Wed, 3 Feb 2016 07:57:52 -0500
> > Paul Moore <paul@paul-moore.com> wrote:
> >
> >> On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> >> > On Wed, 3 Feb 2016 15:34:09 +0530
> >> > Sowndarya K <sowndaryak18@gmail.com> wrote:
> >> >> I am running docker container without privileges and now service
> >> >> auditd start fails to execute even I add capabilities to docker.
> >> >> please try to help me as early as possible
> >> >
> >> > If auditd is being run inside a container, then it has problems
> >> > because the audit subsystem inside the kernel isn't container
> >> > aware/namespaced. I have recently made changes to auditd in svn for
> >> > the next release which allows auditd to run as a log _aggregator_
> >> > inside a container. This means it has no knowledge of events coming
> >> > from within the container but can act as an aggregator for systems
> >> > doing remote logging.
> >>
> >> To add some commentary to this: we are not going to namespace the
> >> audit subsystem like other subsystems, but making audit *aware* of
> >> namespaces is on the todo list.
> >
> > OK. Suppose I go out and rent a virtualized server with root access for
> > my web site. Turns out the company that is leasing me time used
> > containers as their method of virtualizing. my web site runs fine in a
> > container so no big deal. However, as a customer, I would want access
> > to the logs for my container directly in the container. As a matter of
> > fact, its a PCI-DSS requirement to have access to those logs.
> >
> > I really think the audit system _has to be_ namespaced, somehow, for
> > compliance reasons.
>
> Having access to audit events generated inside a namespace (or set of
> namespaces to be more specific), and only generated inside a namespace
> (or set of ...), does not require the audit subsystem to be
> namespaced; however, it does require the audit subsystem to recognize
> namespaces and associate them with events so that they can be tagged
> and routed accordingly. Based on previous conversations, I suspect we
> have the same goals/ideas and are just using different terminology. I
> wouldn't worry too much about it at this point as that work is still
> in the early stages.
I'm late in the conversation, but "what Steve and Paul said". A number
of discussions have already happenned concerning this idea and the goal
is to have auditd be able to run pretty much seamlessly inside a
container without influencing or compromising the auditd running in the
parent namespace(s). From what we have discussed, it appears most
likely that auditd will be anchored one per user namespace.
> paul moore
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* Re: Regarding Auditd fails to start
From: Paul Moore @ 2016-02-03 14:27 UTC (permalink / raw)
To: Steve Grubb; +Cc: Sowndarya K, Linux-audit
In-Reply-To: <20160203150827.0a154257@ivy-bridge>
On Wed, Feb 3, 2016 at 9:08 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wed, 3 Feb 2016 07:57:52 -0500
> Paul Moore <paul@paul-moore.com> wrote:
>
>> On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb@redhat.com> wrote:
>> > On Wed, 3 Feb 2016 15:34:09 +0530
>> > Sowndarya K <sowndaryak18@gmail.com> wrote:
>> >> I am running docker container without privileges and now service
>> >> auditd start fails to execute even I add capabilities to docker.
>> >> please try to help me as early as possible
>> >
>> > If auditd is being run inside a container, then it has problems
>> > because the audit subsystem inside the kernel isn't container
>> > aware/namespaced. I have recently made changes to auditd in svn for
>> > the next release which allows auditd to run as a log _aggregator_
>> > inside a container. This means it has no knowledge of events coming
>> > from within the container but can act as an aggregator for systems
>> > doing remote logging.
>>
>> To add some commentary to this: we are not going to namespace the
>> audit subsystem like other subsystems, but making audit *aware* of
>> namespaces is on the todo list.
>
> OK. Suppose I go out and rent a virtualized server with root access for
> my web site. Turns out the company that is leasing me time used
> containers as their method of virtualizing. my web site runs fine in a
> container so no big deal. However, as a customer, I would want access
> to the logs for my container directly in the container. As a matter of
> fact, its a PCI-DSS requirement to have access to those logs.
>
> I really think the audit system _has to be_ namespaced, somehow, for
> compliance reasons.
Having access to audit events generated inside a namespace (or set of
namespaces to be more specific), and only generated inside a namespace
(or set of ...), does not require the audit subsystem to be
namespaced; however, it does require the audit subsystem to recognize
namespaces and associate them with events so that they can be tagged
and routed accordingly. Based on previous conversations, I suspect we
have the same goals/ideas and are just using different terminology. I
wouldn't worry too much about it at this point as that work is still
in the early stages.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: Regarding Auditd fails to start
From: Steve Grubb @ 2016-02-03 14:08 UTC (permalink / raw)
To: Paul Moore; +Cc: Sowndarya K, Linux-audit
In-Reply-To: <CAHC9VhQkrfCwwhh2x1pfGb1bpBjWCvhGwuw_PwBL4zzhqcNcUQ@mail.gmail.com>
On Wed, 3 Feb 2016 07:57:52 -0500
Paul Moore <paul@paul-moore.com> wrote:
> On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Wed, 3 Feb 2016 15:34:09 +0530
> > Sowndarya K <sowndaryak18@gmail.com> wrote:
> >> I am running docker container without privileges and now service
> >> auditd start fails to execute even I add capabilities to docker.
> >> please try to help me as early as possible
> >
> > If auditd is being run inside a container, then it has problems
> > because the audit subsystem inside the kernel isn't container
> > aware/namespaced. I have recently made changes to auditd in svn for
> > the next release which allows auditd to run as a log _aggregator_
> > inside a container. This means it has no knowledge of events coming
> > from within the container but can act as an aggregator for systems
> > doing remote logging.
>
> To add some commentary to this: we are not going to namespace the
> audit subsystem like other subsystems, but making audit *aware* of
> namespaces is on the todo list.
OK. Suppose I go out and rent a virtualized server with root access for
my web site. Turns out the company that is leasing me time used
containers as their method of virtualizing. my web site runs fine in a
container so no big deal. However, as a customer, I would want access
to the logs for my container directly in the container. As a matter of
fact, its a PCI-DSS requirement to have access to those logs.
I really think the audit system _has to be_ namespaced, somehow, for
compliance reasons.
-Steve
^ permalink raw reply
* Re: Regarding Auditd fails to start
From: Paul Moore @ 2016-02-03 12:57 UTC (permalink / raw)
To: Steve Grubb; +Cc: Sowndarya K, Linux-audit
In-Reply-To: <20160203121619.5b293913@ivy-bridge>
On Wed, Feb 3, 2016 at 6:16 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wed, 3 Feb 2016 15:34:09 +0530
> Sowndarya K <sowndaryak18@gmail.com> wrote:
>> I am running docker container without privileges and now service
>> auditd start fails to execute even I add capabilities to docker.
>> please try to help me as early as possible
>
> If auditd is being run inside a container, then it has problems because
> the audit subsystem inside the kernel isn't container aware/namespaced.
> I have recently made changes to auditd in svn for the next release which
> allows auditd to run as a log _aggregator_ inside a container. This
> means it has no knowledge of events coming from within the container
> but can act as an aggregator for systems doing remote logging.
To add some commentary to this: we are not going to namespace the
audit subsystem like other subsystems, but making audit *aware* of
namespaces is on the todo list.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: Regarding Auditd fails to start
From: Steve Grubb @ 2016-02-03 11:16 UTC (permalink / raw)
To: Sowndarya K; +Cc: Linux-audit
In-Reply-To: <CAKc3OY0QkeBYdbeG=_HEmTMetXThLV22W1qKzQ_ueSkWQLOgdQ@mail.gmail.com>
On Wed, 3 Feb 2016 15:34:09 +0530
Sowndarya K <sowndaryak18@gmail.com> wrote:
> I am running docker container without privileges and now service
> auditd start fails to execute even I add capabilities to docker.
> please try to help me as early as possible
If auditd is being run inside a container, then it has problems because
the audit subsystem inside the kernel isn't container aware/namespaced.
I have recently made changes to auditd in svn for the next release which
allows auditd to run as a log _aggregator_ inside a container. This
means it has no knowledge of events coming from within the container
but can act as an aggregator for systems doing remote logging.
-Steve
^ permalink raw reply
* Regarding Auditd fails to start
From: Sowndarya K @ 2016-02-03 10:04 UTC (permalink / raw)
To: Linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 203 bytes --]
Hello,
I am running docker container without privileges and now service auditd
start fails to execute even i add capabilities to docker. please try to
help me as early as possible
Thanks
Sowndarya K
[-- Attachment #1.2: Type: text/html, Size: 311 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Current Red Hat Kernels 2.6.18 & 2.6.32 not able to have non-existent files in audit.rules?
From: leam hall @ 2016-02-02 19:12 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <20160202200353.22b7e189@ivy-bridge>
[-- Attachment #1.1: Type: text/plain, Size: 909 bytes --]
Thanks Steve! In this case I think we want it to pretend nothing is wrong.
Sadly, that means other errors might get passed over so we have to watch
for those.
Leam
On Tue, Feb 2, 2016 at 2:03 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Tue, 2 Feb 2016 12:05:38 -0500
> leam hall <leamhall@gmail.com> wrote:
>
> > Running into errors where we're pushing out a blanket audit.rules
> > file and some servers don't have some of the files. I've seen the -i
> > and -c suggestion for auditctl but wanted to confirm that that's the
> > right choice. We need to ensure warnings don't choke auditd or make
> > it skip other rules.
>
> -c will make it continue but ultimately report failure.
> -i will make it continue and pretend nothing is wrong.
>
> Either could be correct depending on whether you want success or
> failure final status.
>
> -Steve
>
--
Mind on a Mission <http://leamhall.blogspot.com/>
[-- Attachment #1.2: Type: text/html, Size: 1527 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Current Red Hat Kernels 2.6.18 & 2.6.32 not able to have non-existent files in audit.rules?
From: Steve Grubb @ 2016-02-02 19:03 UTC (permalink / raw)
To: leam hall; +Cc: linux-audit
In-Reply-To: <CACv9p5orRadb_KjYjz8H+OXrnyjBnSztzGJjb6bwKNyjO_YMpg@mail.gmail.com>
On Tue, 2 Feb 2016 12:05:38 -0500
leam hall <leamhall@gmail.com> wrote:
> Running into errors where we're pushing out a blanket audit.rules
> file and some servers don't have some of the files. I've seen the -i
> and -c suggestion for auditctl but wanted to confirm that that's the
> right choice. We need to ensure warnings don't choke auditd or make
> it skip other rules.
-c will make it continue but ultimately report failure.
-i will make it continue and pretend nothing is wrong.
Either could be correct depending on whether you want success or
failure final status.
-Steve
^ permalink raw reply
* Current Red Hat Kernels 2.6.18 & 2.6.32 not able to have non-existent files in audit.rules?
From: leam hall @ 2016-02-02 17:05 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 348 bytes --]
Running into errors where we're pushing out a blanket audit.rules file and
some servers don't have some of the files. I've seen the -i and -c
suggestion for auditctl but wanted to confirm that that's the right choice.
We need to ensure warnings don't choke auditd or make it skip other rules.
--
Mind on a Mission <http://leamhall.blogspot.com/>
[-- Attachment #1.2: Type: text/html, Size: 498 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: audit 1.7.18 and auparse_feed_has_data
From: Steve Grubb @ 2016-02-01 12:20 UTC (permalink / raw)
To: Lev Stipakov; +Cc: linux-audit
In-Reply-To: <n8ngmq$2tk$1@ger.gmane.org>
On Mon, 1 Feb 2016 13:48:42 +0200
Lev Stipakov <lstipakov@gmail.com> wrote:
> Hi,
>
> I have a Debian 7.9 which includes libaudit-devel-1.7.18. That
> version does not have auparse_feed_has_data(). Its implementation
> looks simple, however it uses au_lo, which is declared as static in
> auparse.c and therefore cannot be accessed outside of that file.
>
> I took auparse_feed_has_data() usage from audisp-example.c
>
> tv.tv_sec = 5;
> tv.tv_usec = 0;
> FD_ZERO(&read_mask);
> FD_SET(0, &read_mask);
> if (auparse_feed_has_data(au))
> retval= select(1, &read_mask, NULL, NULL, &tv);
> else
> retval= select(1, &read_mask, NULL, NULL, NULL);
>
> I noticed that old version of example plugin doesn't have
> auparse_feed_has_data() or select() calls
> (https://github.com/gdestuynder/audit-cef/blob/master/contrib/plugin/audisp-example.c#L104)
>
> What is the purpose of select/auparse_feed_has_data? Is it some kind
> of optimization or bug fix?
A little of both. See this thread for the background:
https://www.redhat.com/archives/linux-audit/2012-August/msg00025.html
> Since I have to support Debian 7 and
> probably have to stick to audit 1.7 headers, is it safe to use the
> "old way"?
>
> -Lev
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* audit 1.7.18 and auparse_feed_has_data
From: Lev Stipakov @ 2016-02-01 11:48 UTC (permalink / raw)
To: linux-audit
Hi,
I have a Debian 7.9 which includes libaudit-devel-1.7.18. That version
does not have auparse_feed_has_data(). Its implementation looks simple,
however it uses au_lo, which is declared as static in auparse.c and
therefore cannot be accessed outside of that file.
I took auparse_feed_has_data() usage from audisp-example.c
tv.tv_sec = 5;
tv.tv_usec = 0;
FD_ZERO(&read_mask);
FD_SET(0, &read_mask);
if (auparse_feed_has_data(au))
retval= select(1, &read_mask, NULL, NULL, &tv);
else
retval= select(1, &read_mask, NULL, NULL, NULL);
I noticed that old version of example plugin doesn't have
auparse_feed_has_data() or select() calls
(https://github.com/gdestuynder/audit-cef/blob/master/contrib/plugin/audisp-example.c#L104)
What is the purpose of select/auparse_feed_has_data? Is it some kind of
optimization or bug fix? Since I have to support Debian 7 and probably
have to stick to audit 1.7 headers, is it safe to use the "old way"?
-Lev
^ permalink raw reply
* Re: audit rules placement
From: Steve Grubb @ 2016-01-29 12:04 UTC (permalink / raw)
To: Lev Stipakov; +Cc: linux-audit
In-Reply-To: <n8ffdb$ttl$1@ger.gmane.org>
On Fri, 29 Jan 2016 12:37:31 +0200
Lev Stipakov <lstipakov@gmail.com> wrote:
> Hello,
>
> I have a rpm/deb package which includes audisp plugin. In order
> plugin to work, I need to permanently add audit rules. It seems that
> for Centos/RHEL 7 I need to put those
> into audit.rules and for Centos/RHEL6 (and
> probably Debian / Ubuntu?) it is /etc/audit/audit.rules.
>
> I noticed however that at least on Centos 7 I could put my rules into
> /etc/audit/rules.d/plugin.rules and they will be picked on auditd
> restart and added to /etc/audit/audit.rules. This does not work on
> Debian 8 - even though it has ruled.d directory only rules from
> /rules.d/audit.rules are used.
>
> Is there some kind of "official" guidance to where I should put my
> rules on Centos/RHEL/Debian/Ubuntu ?
/etc/audit/rules.d/ is where you should put rules for all recent audit
packages. You may need to advise them to enable augenrules. For
anything older, it needs to be inserted into audit.rules.
-Steve
> -Lev
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* audit rules placement
From: Lev Stipakov @ 2016-01-29 10:37 UTC (permalink / raw)
To: linux-audit
Hello,
I have a rpm/deb package which includes audisp plugin. In order plugin
to work, I need to permanently add audit rules. It seems that for
Centos/RHEL 7 I need to put those into /etc/audit/rules.d/audit.rules
and for Centos/RHEL6 (and probably Debian / Ubuntu?) it is
/etc/audit/audit.rules.
I noticed however that at least on Centos 7 I could put my rules into
/etc/audit/rules.d/plugin.rules and they will be picked on auditd
restart and added to /etc/audit/audit.rules. This does not work on
Debian 8 - even though it has ruled.d directory only rules from
/rules.d/audit.rules are used.
Is there some kind of "official" guidance to where I should put my rules
on Centos/RHEL/Debian/Ubuntu ?
-Lev
^ permalink raw reply
* Re: Auditing network traffic
From: Steve Grubb @ 2016-01-21 22:09 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <56A14461.2020109@gmail.com>
On Thursday, January 21, 2016 10:49:37 PM Lev Stipakov wrote:
> Sorry, I probably was not clear here. I am able to catch packets by
> adding iptables rules like ones you've mentioned and process events
> (with record type AUDIT_NETFILTER_PKT) by code inside my plugin.
>
> The problem is, I would prefer them not to be written to logfiles. My
> business logic does not require that (everything is handled by plugin
> code), and I noticed that logs are rotated quite fast (I capture all
> incoming/outgoing packets). So, is there any way to disable logging and
> make audit deliver those events to plugin only?
In /etc/audit/auditd.conf make log_firmat like this:
log_format = NOLOG
and auditd will not log anything to disk.
-Steve
^ permalink raw reply
* Re: Auditing network traffic
From: Lev Stipakov @ 2016-01-21 20:49 UTC (permalink / raw)
To: Steve Grubb, linux-audit
In-Reply-To: <13584577.zLtyaCJgkZ@x2>
On 21.01.2016 18:50, Steve Grubb wrote:
> I'd say it would be better because you don't have to do nearly as much work.
> The kernel takes care of all the heavy lifting and you just filter on
> NETFILTER_PKT events.
Good to know, thanks!
> There are plenty of examples of how to do logging of netfilter events. You can
> just copy the examples and substitute AUDIT as the target (but you have to add
> a --type argument after it). A couple examples I found after a quick search:
Sorry, I probably was not clear here. I am able to catch packets by
adding iptables rules like ones you've mentioned and process events
(with record type AUDIT_NETFILTER_PKT) by code inside my plugin.
The problem is, I would prefer them not to be written to logfiles. My
business logic does not require that (everything is handled by plugin
code), and I noticed that logs are rotated quite fast (I capture all
incoming/outgoing packets). So, is there any way to disable logging and
make audit deliver those events to plugin only?
-Lev
^ permalink raw reply
* Re: Auditing network traffic
From: Steve Grubb @ 2016-01-21 16:50 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <56A0A999.9090401@gmail.com>
On Thursday, January 21, 2016 11:49:13 AM Lev Stipakov wrote:
> Thank you for your comments! It seems that AUDIT target is better option
> than hooking syscalls and managing fds. I don't have to look inside
> traffic, just src/dest and bytes count is enough for me.
>
> What would be the performance implications of that approach comparison
> to, say, libpcap option?
I'd say it would be better because you don't have to do nearly as much work.
The kernel takes care of all the heavy lifting and you just filter on
NETFILTER_PKT events.
> Mostly I am concerned about logging part - seems that every packet produces
> NETFILTER_PKT record. I could not find any way to disable that, except
> probably disabling logging all together but that will break ausearch.
There are plenty of examples of how to do logging of netfilter events. You can
just copy the examples and substitute AUDIT as the target (but you have to add
a --type argument after it). A couple examples I found after a quick search:
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j AUDIT --type accept
To get any connection attempt:
iptables -I INPUT -p tcp --tcp-flags ALL SYN -j AUDIT --type accept
Of course any use of nmap -sS will flood the logs on this one. But you can
write any kind of netfilter rule. The examples in iptables-extensions man page
are quite limited when compared to what you can really do.
Maybe I should update an audit man page to show some real world examples. If
anyone would like to suggest a few examples, I'll see about adding them.
-Steve
^ permalink raw reply
* Re: Auditing network traffic
From: Lev Stipakov @ 2016-01-21 9:49 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <3655233.WIOkSfVQiu@x2>
Hi Steve,
Thank you for your comments! It seems that AUDIT target is better option
than hooking syscalls and managing fds. I don't have to look inside
traffic, just src/dest and bytes count is enough for me.
What would be the performance implications of that approach comparison
to, say, libpcap option? Mostly I am concerned about logging part -
seems that every packet produces NETFILTER_PKT record. I could not find
any way to disable that, except probably disabling logging all together
but that will break ausearch.
-Lev
^ permalink raw reply
* Re: Auditing network traffic
From: Peter Moody @ 2016-01-21 5:19 UTC (permalink / raw)
To: Lev Stipakov; +Cc: linux-audit
In-Reply-To: <n7o5eq$4qj$1@ger.gmane.org>
I actually did a bunch of work for this at a previous job. it was
supposed to be opensource'd, but then I switched jobs and the new
internal-maintainer never got around to opening it up :(
My short answer is that audit is probably the wrong tool for this,
especially for machines pushing a large amount of traffic.
the longer answer is that you can do it if you hook the discrete
events in the kernel and then correlate them later in your pipeline.
IIRC, the events you need are:
* fork/exec/exit to correlate pid with proc information (exe, argv)
* socket open/close & sock_sendmsg/sock_recvmsg to correlate socket
to pid (i think you might be able to get way without hooking socket
open/close and just hook sendmsg/recvmsg)
* netfilters to correlate saddr/daddr + packet contents with sockets.
the linux sensor module (https://github.com/HoneProject/Linux-Sensor)
did most of this but there were a bunch of issues that made it
unsuitable for enterprise use (funding dried up so the folks at pnnl
who had done all of the heavy lifting weren't able to finish). the
internal fork fixed these issues but like I said, I left before I got
a chance to upstream the fixes.
you could also look at the sysdig module for this.
Cheers,
peter
On Wed, Jan 20, 2016 at 6:26 AM, Lev Stipakov <lstipakov@gmail.com> wrote:
> Hello,
>
> I work on an audisp plugin which audits network traffic – what process has
> send/received data to/from what remote address. So far I see 2 ways of
> accomplishing that:
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Auditing network traffic
From: Paul Moore @ 2016-01-20 21:40 UTC (permalink / raw)
To: Lev Stipakov; +Cc: linux-audit
In-Reply-To: <n7o5eq$4qj$1@ger.gmane.org>
On Wed, Jan 20, 2016 at 9:26 AM, Lev Stipakov <lstipakov@gmail.com> wrote:
> Another way of getting network stats is the AUDIT target for netfilter.
> Looks good, no need to worry about fds/addrs. However there is no pid. What
> would be the ”best” way to get pid for those records? Anything else besides
> looking into /proc/net/tcp?
Linking a specific process/PID to a network packet is very difficult,
if not impossible, for the simple reason that the kernel doesn't track
the originating process, only the originating socket (which is an
unreliable way to determine the sending process). Not to mention the
fact Steve already mentioned that some packets do not originate in
userspace; forwarded traffic, streaming protocol control messages,
ICMP error messages are all common examples of non-local userspace
generated messages.
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Auditing network traffic
From: Steve Grubb @ 2016-01-20 18:30 UTC (permalink / raw)
To: F Rafi; +Cc: linux-audit@redhat.com
In-Reply-To: <CABXp1cuXBeKcGaeYcSiZeKc9AwXwcNZSNLqL3G8d2wrAjhm1NA@mail.gmail.com>
On Wednesday, January 20, 2016 01:05:45 PM F Rafi wrote:
> Perhaps this is of use. My goal was to restrict audit logs to outbound
> connections only to reduce the amount of logs.
>
> # Outbound connections could indicate exfiltration of data (connect vs
> accept)
> # Log 64 bit processes (a2!=6e filters local unix socket calls)
>
> -a exit,always -F arch=b64 -S connect -F a2!=110 -k network_outbound64
This is good for TCP connections. There's always UDP where you would need
sendto and sendmsg. Imagine someone exfiltrating on what seems to be DNS lookup
requests.
The IPTables AUDIT target is what is really meant to audit information flow in
or out of the system. I think this is the first discussion on the mail list
where someone might be trying to use it. I'm hoping this leads to making it
better.
-Steve
> # Log 32 bit processes (a0=3 means only outbound sys_connect calls)
>
> -a exit,always -F arch=b32 -S socketcall -F a0=3 -k network_outbound32
>
>
> -Farhan
>
> PS: I'd appreciate if someone could poke holes in this.
>
> On Wed, Jan 20, 2016 at 10:29 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Wednesday, January 20, 2016 10:18:29 AM Steve Grubb wrote:
> > > > I work on an audisp plugin which audits network traffic – what process
> > > > has send/received data to/from what remote address. So far I see 2
> > > > ways
> > > > of accomplishing that:
> > > >
> > > > Hook syscalls. First, hook socket call with af_inet/inet6 to get pid
> >
> > and
> >
> > > > fd, then read/write/sendto/recvfrom filtered by pid and fd
> >
> > One other thing, read and write will tell you that a read or write
> > happened.
> > It does not record what was read or written. If you need that, you will
> > have
> > to sniff network traffic. Audit won't be able to help much.
> >
> > -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
^ 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