om "signal" and "trigger" to "register"
- restrict registration to single process or force all threads and children
into same container
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, Su
On 2017-09-20 16:52, Paul Moore wrote:
> On Wed, Aug 23, 2017 at 7:03 AM, Richard Guy Briggs <r...@redhat.com> wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > re
On 2017-09-20 16:52, Paul Moore wrote:
> On Wed, Aug 23, 2017 at 7:03 AM, Richard Guy Briggs wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > records on a few modul
Factor out the case of privileged root from the function
cap_bprm_set_creds() to make the latter easier to read and analyse.
Suggested-by: Serge Hallyn <se...@hallyn.com>
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
Reviewed-by: Serge Hallyn <se...@hallyn.com>
Acke
Factor out the case of privileged root from the function
cap_bprm_set_creds() to make the latter easier to read and analyse.
Suggested-by: Serge Hallyn
Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
Rename has_cap to has_fcap to clarify it applies to file capabilities
since the entire source file is about capabilities.
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
Reviewed-by: Serge Hallyn <se...@hallyn.com>
Acked-by: James Morris <james.l.mor...@oracle.com>
Acked-by
Rename has_cap to has_fcap to clarify it applies to file capabilities
since the entire source file is about capabilities.
Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
---
security/commoncap.c | 20
Move the audit log decision logic to its own function to isolate the
complexity in one place.
Suggested-by: Serge Hallyn <se...@hallyn.com>
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
Reviewed-by: Serge Hallyn <se...@hallyn.com>
Acked-by: James Morris <james.l.mor
Move the audit log decision logic to its own function to isolate the
complexity in one place.
Suggested-by: Serge Hallyn
Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
---
security/commoncap.c | 50
The way the logic was presented, it was awkward to read and verify.
Invert the logic using DeMorgan's Law to be more easily able to read and
understand.
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
Reviewed-by: Serge Hallyn <se...@hallyn.com>
Acked-by: James Morris
The way the logic was presented, it was awkward to read and verify.
Invert the logic using DeMorgan's Law to be more easily able to read and
understand.
Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
See: https://github.com/linux-audit/audit-kernel/issues/16
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
Reviewed-by: Serge Hallyn <se...@hallyn.com>
Acked-by: James Morris <james.l.mor...@oracle.com>
Acked-by: Kees Cook <keesc...@chromium.org>
Acked-by: Paul Moore &
ained)
- If it is a non-setuid file and it gets ambient capabilities, we want
the capabilities.
!is_setuid && pA_gained
- These last two are combined into one due to the common first parameter.
Related: https://github.com/linux-audit/audit-kernel/issues/16
Signed-off-by: Ri
See: https://github.com/linux-audit/audit-kernel/issues/16
Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Acked-by: Paul Moore
---
security/commoncap.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/security/com
ained)
- If it is a non-setuid file and it gets ambient capabilities, we want
the capabilities.
!is_setuid && pA_gained
- These last two are combined into one due to the common first parameter.
Related: https://github.com/linux-audit/audit-kernel/issues/16
Signed-off-by: Richa
Remove a layer of conditional logic to make the use of conditions
easier to read and analyse.
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
Reviewed-by: Serge Hallyn <se...@hallyn.com>
Acked-by: James Morris <james.l.mor...@oracle.com>
Acked-by: Kees Cook <keesc...@chr
Remove a layer of conditional logic to make the use of conditions
easier to read and analyse.
Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
---
security/commoncap.c | 23 ++-
1 file
Introduce a number of inlines to make the use of the negation of
uid_eq() easier to read and analyse.
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
Reviewed-by: Serge Hallyn <se...@hallyn.com>
Acked-by: James Morris <james.l.mor...@oracle.com>
Acked-by: Kees Cook <
Introduce a number of inlines to make the use of the negation of
uid_eq() easier to read and analyse.
Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
---
security/commoncap.c | 28
nto handle_privileged_root()
v4
rebase on kees' 4.13 commoncap changes
minor local func renames
v3
refactor into several sub-functions
convert most macros to inline funcs
v2
use macros to clarify intent of calculations
fix original logic error
address additional audit logging co
Introduce macros cap_gained, cap_grew, cap_full to make the use of the
negation of is_subset() easier to read and analyse.
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
Reviewed-by: Serge Hallyn <se...@hallyn.com>
Acked-by: James Morris <james.l.mor...@oracle.com>
Acked-by
nto handle_privileged_root()
v4
rebase on kees' 4.13 commoncap changes
minor local func renames
v3
refactor into several sub-functions
convert most macros to inline funcs
v2
use macros to clarify intent of calculations
fix original logic error
address additional audit logging co
Introduce macros cap_gained, cap_grew, cap_full to make the use of the
negation of is_subset() easier to read and analyse.
Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
---
security/commoncap.c | 18
Introduce inline root_privileged() to make use of SECURE_NONROOT
easier to read.
Suggested-by: Serge Hallyn <se...@hallyn.com>
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
Reviewed-by: Serge Hallyn <se...@hallyn.com>
Acked-by: James Morris <james.l.mor...@oracle.com
Introduce inline root_privileged() to make use of SECURE_NONROOT
easier to read.
Suggested-by: Serge Hallyn
Signed-off-by: Richard Guy Briggs
Reviewed-by: Serge Hallyn
Acked-by: James Morris
Acked-by: Kees Cook
Okay-ished-by: Paul Moore
---
security/commoncap.c | 6 --
1 file changed
On 2017-09-20 12:52, Paul Moore wrote:
> On Wed, Aug 23, 2017 at 7:03 AM, Richard Guy Briggs <r...@redhat.com> wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > re
On 2017-09-20 12:52, Paul Moore wrote:
> On Wed, Aug 23, 2017 at 7:03 AM, Richard Guy Briggs wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > records on a few modul
On 2017-09-18 21:45, Eric W. Biederman wrote:
> Richard Guy Briggs <r...@redhat.com> writes:
>
> > On 2017-09-14 12:33, Eric W. Biederman wrote:
> >> Richard Guy Briggs <r...@redhat.com> writes:
> >>
> >> > The trigger is a pseudo filesys
On 2017-09-18 21:45, Eric W. Biederman wrote:
> Richard Guy Briggs writes:
>
> > On 2017-09-14 12:33, Eric W. Biederman wrote:
> >> Richard Guy Briggs writes:
> >>
> >> > The trigger is a pseudo filesystem (proc, since PID tree already exists)
> &
On 2017-09-14 01:30, Richard Guy Briggs wrote:
> On 2017-09-13 14:33, Carlos O'Donell wrote:
> > On 09/13/2017 12:13 PM, Richard Guy Briggs wrote:
> > > Containers are a userspace concept. The kernel knows nothing of them.
> >
> > I am looking at this RF
On 2017-09-14 01:30, Richard Guy Briggs wrote:
> On 2017-09-13 14:33, Carlos O'Donell wrote:
> > On 09/13/2017 12:13 PM, Richard Guy Briggs wrote:
> > > Containers are a userspace concept. The kernel knows nothing of them.
> >
> > I am looking at this RF
On 2017-09-14 12:33, Eric W. Biederman wrote:
> Richard Guy Briggs <r...@redhat.com> writes:
>
> > The trigger is a pseudo filesystem (proc, since PID tree already exists)
> > write of a u64 representing the container ID to a file representing a
> > process that
On 2017-09-14 12:33, Eric W. Biederman wrote:
> Richard Guy Briggs writes:
>
> > The trigger is a pseudo filesystem (proc, since PID tree already exists)
> > write of a u64 representing the container ID to a file representing a
> > process that will become the first pr
On 2017-09-06 09:03, Serge E. Hallyn wrote:
> Quoting Richard Guy Briggs (r...@redhat.com):
> ...
> > > I believe we are going to need a container ID to container definition
> > > (namespace, etc.) mapping mechanism regardless of if the container ID
> > > is
On 2017-09-06 09:03, Serge E. Hallyn wrote:
> Quoting Richard Guy Briggs (r...@redhat.com):
> ...
> > > I believe we are going to need a container ID to container definition
> > > (namespace, etc.) mapping mechanism regardless of if the container ID
> > > is
On 2017-09-13 14:33, Carlos O'Donell wrote:
> On 09/13/2017 12:13 PM, Richard Guy Briggs wrote:
> > Containers are a userspace concept. The kernel knows nothing of them.
>
> I am looking at this RFC from a userspace perspective, particularly from
> the loader's point of vi
On 2017-09-13 14:33, Carlos O'Donell wrote:
> On 09/13/2017 12:13 PM, Richard Guy Briggs wrote:
> > Containers are a userspace concept. The kernel knows nothing of them.
>
> I am looking at this RFC from a userspace perspective, particularly from
> the loader's point of vi
container. A namespace can be
moved from one container to another indirectly by having that namespace
used in a second process in another container and then ending all the
processes in the first container.
Feedback please.
- RGB
--
Richard Guy Briggs <r...@redhat.com>
Sr. S/W Engineer, Kernel Security
container. A namespace can be
moved from one container to another indirectly by having that namespace
used in a second process in another container and then ending all the
processes in the first container.
Feedback please.
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Syst
ce and therefore untrusted anyways.
> This isn't strictly a problem with this patch, but I think we should
> be able to get rid of the 'comm' variable in this if-block as simply
> reuse the 'comm' from the top of the function. It would be nice to
> include that in this patch.
>
> Other than that
h this patch, but I think we should
> be able to get rid of the 'comm' variable in this if-block as simply
> reuse the 'comm' from the top of the function. It would be nice to
> include that in this patch.
>
> Other than that minor nit, this patch looks good to me; if you make
See: https://github.com/linux-audit/audit-kernel/issues/16
See: https://github.com/linux-audit/audit-userspace/issues/8
Test case: https://github.com/linux-audit/audit-testsuite/issues/42
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
---
v3: rebase
v2: convert AUDIT_FILTER_PATH to
See: https://github.com/linux-audit/audit-kernel/issues/16
See: https://github.com/linux-audit/audit-userspace/issues/8
Test case: https://github.com/linux-audit/audit-testsuite/issues/42
Signed-off-by: Richard Guy Briggs
---
v3: rebase
v2: convert AUDIT_FILTER_PATH to AUDIT_FILTER_FS
---
include/
issues/8
Test case: https://github.com/linux-audit/audit-testsuite/issues/42
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
---
v3:
fix audit_buffer leak and dname error allocation leak audit_log_name
only put audit_name->dentry if it is being replaced
v2:
minor cosmetic changes an
issues/8
Test case: https://github.com/linux-audit/audit-testsuite/issues/42
Signed-off-by: Richard Guy Briggs
---
v3:
fix audit_buffer leak and dname error allocation leak audit_log_name
only put audit_name->dentry if it is being replaced
v2:
minor cosmetic changes and support fs filter pat
On 2017-08-16 18:21, Paul Moore wrote:
> On Mon, Aug 14, 2017 at 1:47 AM, Richard Guy Briggs <r...@redhat.com> wrote:
> > Hi David,
> >
> > I wanted to respond to this thread to attempt some constructive feedback,
> > better late than never. I had a look at
On 2017-08-16 18:21, Paul Moore wrote:
> On Mon, Aug 14, 2017 at 1:47 AM, Richard Guy Briggs wrote:
> > Hi David,
> >
> > I wanted to respond to this thread to attempt some constructive feedback,
> > better late than never. I had a look at your fsopen/fsmount() patc
fs_struct *new_fs)
> {
> struct nsproxy *new_nsp;
> @@ -72,39 +73,39 @@ static struct nsproxy *create_new_namespaces(unsigned
> long flags,
> if (!new_nsp)
> return ERR_PTR(-ENOMEM);
>
> - new_nsp->mnt_ns = copy_mnt_ns(flags, tsk->nsproxy->
gt; {
> struct nsproxy *new_nsp;
> @@ -72,39 +73,39 @@ static struct nsproxy *create_new_namespaces(unsigned
> long flags,
> if (!new_nsp)
> return ERR_PTR(-ENOMEM);
>
> - new_nsp->mnt_ns = copy_mnt_ns(flags, tsk->nsproxy->mnt_ns, user_ns,
> new
On 2017-08-11 02:36, Richard Guy Briggs wrote:
> On 2017-06-28 15:03, Paul Moore wrote:
> > On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs <r...@redhat.com> wrote:
> > > On 2017-05-30 17:21, Paul Moore wrote:
> > >> On Tue, Apr 4, 2017 at 5:21 AM,
On 2017-08-11 02:36, Richard Guy Briggs wrote:
> On 2017-06-28 15:03, Paul Moore wrote:
> > On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote:
> > > On 2017-05-30 17:21, Paul Moore wrote:
> > >> On Tue, Apr 4, 2017 at 5:21 AM, Ric
On 2017-06-28 15:03, Paul Moore wrote:
> On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs <r...@redhat.com> wrote:
> > On 2017-05-30 17:21, Paul Moore wrote:
> >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs <r...@redhat.com> wrote:
>
> ...
>
>
On 2017-06-28 15:03, Paul Moore wrote:
> On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote:
> > On 2017-05-30 17:21, Paul Moore wrote:
> >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote:
>
> ...
>
> >> > diff --git a/kernel/audit.
y creating a y2038 safe kernel image
> that is free of timespec.
>
> The syscall interfaces themselves are not changed as part
> of the patch. They will be part of a different series.
>
> Signed-off-by: Deepa Dinamani <deepa.ker...@gmail.com>
> Cc: Paul Moore <
y creating a y2038 safe kernel image
> that is free of timespec.
>
> The syscall interfaces themselves are not changed as part
> of the patch. They will be part of a different series.
>
> Signed-off-by: Deepa Dinamani
> Cc: Paul Moore
> Cc: Richard Guy Briggs
Looks
This looks fine to me. Audit has its own event counter so the slightly
coarser granularity of this counter to avoid the overhead shouldn't be a
significant problem.
Reviewed-by: Richard Guy Briggs <r...@redhat.com>
> paul moore
- RGB
--
Richard Guy Briggs <r...@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
ring
> the current window; while the patch is small, I like to give things
> some time in linux-next before sending them up.
This looks fine to me. Audit has its own event counter so the slightly
coarser granularity of this counter to avoid the overhead shouldn't be a
significant problem.
Review
On 2017-06-29 19:58, Steven Rostedt wrote:
> On Thu, 29 Jun 2017 17:21:22 -0400
> Richard Guy Briggs <r...@redhat.com> wrote:
>
> > > Looking at this again today, why would we want to clear name->dentry
> > > in audit_copy_inode() if it is already set? Does
On 2017-06-29 19:58, Steven Rostedt wrote:
> On Thu, 29 Jun 2017 17:21:22 -0400
> Richard Guy Briggs wrote:
>
> > > Looking at this again today, why would we want to clear name->dentry
> > > in audit_copy_inode() if it is already set? Does that ever happ
On 2017-06-28 15:03, Paul Moore wrote:
> On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs <r...@redhat.com> wrote:
> > On 2017-05-30 17:21, Paul Moore wrote:
> >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs <r...@redhat.com> wrote:
>
> ...
>
>
On 2017-06-28 15:03, Paul Moore wrote:
> On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote:
> > On 2017-05-30 17:21, Paul Moore wrote:
> >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote:
>
> ...
>
> >> > diff --git a/kernel/audit.
On 2017-06-28 15:08, Paul Moore wrote:
> On Tue, Jun 27, 2017 at 4:45 PM, Richard Guy Briggs <r...@redhat.com> wrote:
> > On 2017-05-30 17:30, Paul Moore wrote:
> >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs <r...@redhat.com> wrote:
> >> >
On 2017-06-28 15:08, Paul Moore wrote:
> On Tue, Jun 27, 2017 at 4:45 PM, Richard Guy Briggs wrote:
> > On 2017-05-30 17:30, Paul Moore wrote:
> >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote:
> >> > Tracefs or debugfs were causing hundred
On 2017-05-30 17:21, Paul Moore wrote:
> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs <r...@redhat.com> wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > re
On 2017-05-30 17:21, Paul Moore wrote:
> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > records on a few modules wh
On 2017-05-30 17:30, Paul Moore wrote:
> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs <r...@redhat.com> wrote:
> > Tracefs or debugfs were causing hundreds to thousands of PATH records to
> > be associated with the init_module and finit_module SYSCALL records on a
On 2017-05-30 17:30, Paul Moore wrote:
> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote:
> > Tracefs or debugfs were causing hundreds to thousands of PATH records to
> > be associated with the init_module and finit_module SYSCALL records on a
> > few modules wh
-audit/audit-userspace/issues/15
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
---
include/uapi/linux/audit.h |6 +++---
kernel/auditfilter.c | 10 +-
kernel/auditsc.c |2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/uapi
-audit/audit-userspace/issues/15
Signed-off-by: Richard Guy Briggs
---
include/uapi/linux/audit.h |6 +++---
kernel/auditfilter.c | 10 +-
kernel/auditsc.c |2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/uapi/linux/audit.h b/include
On 2017-06-12 14:33, Derek Robson wrote:
> Fixed checkpatch.pl warnings of "function definition argument FOO
> should also have an identifier name"
>
> Signed-off-by: Derek Robson <robso...@gmail.com>
Sounds reasonable.
Reviewed-by: Richard Guy Briggs <r...@redha
On 2017-06-12 14:33, Derek Robson wrote:
> Fixed checkpatch.pl warnings of "function definition argument FOO
> should also have an identifier name"
>
> Signed-off-by: Derek Robson
Sounds reasonable.
Reviewed-by: Richard Guy Briggs
> -
On 2017-04-04 17:19, Paul Moore wrote:
> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs <r...@redhat.com> wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > re
On 2017-04-04 17:19, Paul Moore wrote:
> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > records on a few modules wh
On 2017-04-04 05:21, Richard Guy Briggs wrote:
> Tracefs or debugfs were causing hundreds to thousands of PATH records to
> be associated with the init_module and finit_module SYSCALL records on a
> few modules when the following rule was in place for startup:
> -a always,exit -F
On 2017-04-04 05:21, Richard Guy Briggs wrote:
> Tracefs or debugfs were causing hundreds to thousands of PATH records to
> be associated with the init_module and finit_module SYSCALL records on a
> few modules when the following rule was in place for startup:
> -a always,exit -F
issues/8
Test case: https://github.com/linux-audit/audit-testsuite/issues/42
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
---
include/linux/audit.h |8
kernel/audit.c| 16
kernel/audit.h|1 +
kernel/auditsc.c |8 +++-
4 fil
issues/8
Test case: https://github.com/linux-audit/audit-testsuite/issues/42
Signed-off-by: Richard Guy Briggs
---
include/linux/audit.h |8
kernel/audit.c| 16
kernel/audit.h|1 +
kernel/auditsc.c |8 +++-
4 files changed, 28 inserti
github.com/linux-audit/audit-kernel/issues/16
Test case: https://github.com/linux-audit/audit-testsuite/issues/42
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
---
include/uapi/linux/audit.h |8 ++--
kernel/auditfilter.c | 39 ---
github.com/linux-audit/audit-kernel/issues/16
Test case: https://github.com/linux-audit/audit-testsuite/issues/42
Signed-off-by: Richard Guy Briggs
---
include/uapi/linux/audit.h |8 ++--
kernel/auditfilter.c | 39 ---
kernel/auditsc.c
htons(ETH_P_IPV6):
> + fam = audit_ip6(ab, skb) ? NFPROTO_IPV6 : -1;
> + break;
> + }
> + break;
> case NFPROTO_IPV4:
> - audit_ip4(ab, skb);
> + fam = audit_ip4(ab, skb) ? NFPROTO_IPV4
htons(ETH_P_IPV6):
> + fam = audit_ip6(ab, skb) ? NFPROTO_IPV6 : -1;
> + break;
> + }
> + break;
> case NFPROTO_IPV4:
> - audit_ip4(ab, skb);
> + fam = audit_ip4(ab, skb) ? NFPROTO_IPV4 : -1;
> break;
> -
> case NFPROTO_IPV6:
> - audit_ip6(ab, skb);
> + fam = audit_ip6(ab, skb) ? NFPROTO_IPV6 : -1;
> break;
> }
>
- RGB
--
Richard Guy Briggs
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
result code will list the return code.
See: https://github.com/linux-audit/audit-kernel/issues/37
https://github.com/linux-audit/audit-kernel/issues/7
https://github.com/linux-audit/audit-kernel/wiki/RFE-Module-Load-Record-Format
Signed-off-by: Richard Guy Briggs <r...@redhat.
result code will list the return code.
See: https://github.com/linux-audit/audit-kernel/issues/37
https://github.com/linux-audit/audit-kernel/issues/7
https://github.com/linux-audit/audit-kernel/wiki/RFE-Module-Load-Record-Format
Signed-off-by: Richard Guy Briggs
---
kernel/module.c
On 2017-03-09 16:15, peter enderborg wrote:
> On 03/09/2017 03:08 PM, Richard Guy Briggs wrote:
> > Record the module name of a delete_module call.
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/37
> >
> > Signed-off-by: Richard Guy Briggs <
On 2017-03-09 16:15, peter enderborg wrote:
> On 03/09/2017 03:08 PM, Richard Guy Briggs wrote:
> > Record the module name of a delete_module call.
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/37
> >
> > Signed-off-by: Richard Guy Briggs
&g
Record the module name of a delete_module call.
See: https://github.com/linux-audit/audit-kernel/issues/37
Signed-off-by: Richard Guy Briggs <r...@redhat.com>
---
kernel/module.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
Record the module name of a delete_module call.
See: https://github.com/linux-audit/audit-kernel/issues/37
Signed-off-by: Richard Guy Briggs
---
kernel/module.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 5432dbe..633f6da
On 2017-03-08 08:25, Richard Guy Briggs wrote:
> On 2017-03-07 14:23, Paul Moore wrote:
> > On Tue, Mar 7, 2017 at 1:44 PM, Paul Moore <p...@paul-moore.com> wrote:
> > > On Tue, Mar 7, 2017 at 10:55 AM, Richard Guy Briggs <r...@redhat.com>
> > > wrote:
>
On 2017-03-08 08:25, Richard Guy Briggs wrote:
> On 2017-03-07 14:23, Paul Moore wrote:
> > On Tue, Mar 7, 2017 at 1:44 PM, Paul Moore wrote:
> > > On Tue, Mar 7, 2017 at 10:55 AM, Richard Guy Briggs
> > > wrote:
> > >> On 2017-03-07 09:29, Paul Moore wrot
On 2017-03-07 14:23, Paul Moore wrote:
> On Tue, Mar 7, 2017 at 1:44 PM, Paul Moore <p...@paul-moore.com> wrote:
> > On Tue, Mar 7, 2017 at 10:55 AM, Richard Guy Briggs <r...@redhat.com> wrote:
> >> On 2017-03-07 09:29, Paul Moore wrote:
> >>> On Mon, Mar
On 2017-03-07 14:23, Paul Moore wrote:
> On Tue, Mar 7, 2017 at 1:44 PM, Paul Moore wrote:
> > On Tue, Mar 7, 2017 at 10:55 AM, Richard Guy Briggs wrote:
> >> On 2017-03-07 09:29, Paul Moore wrote:
> >>> On Mon, Mar 6, 2017 at 11:03 PM, Richard Guy Briggs
> &g
On 2017-03-07 14:09, Steven Rostedt wrote:
> On Tue, 7 Mar 2017 13:34:47 -0500
> Richard Guy Briggs <r...@redhat.com> wrote:
>
> > On 2017-03-07 13:04, Steven Rostedt wrote:
> > > On Tue, 7 Mar 2017 12:39:55 -0500
> > > Richard Guy Briggs <r...@redha
On 2017-03-07 14:09, Steven Rostedt wrote:
> On Tue, 7 Mar 2017 13:34:47 -0500
> Richard Guy Briggs wrote:
>
> > On 2017-03-07 13:04, Steven Rostedt wrote:
> > > On Tue, 7 Mar 2017 12:39:55 -0500
> > > Richard Guy Briggs wrote:
> > >
> > >
On 2017-03-07 13:04, Steven Rostedt wrote:
> On Tue, 7 Mar 2017 12:39:55 -0500
> Richard Guy Briggs <r...@redhat.com> wrote:
>
> > We normally don't expect the init_module syscall to have any PATH
> > records associated with it, so when a few of them had hundreds or m
On 2017-03-07 13:04, Steven Rostedt wrote:
> On Tue, 7 Mar 2017 12:39:55 -0500
> Richard Guy Briggs wrote:
>
> > We normally don't expect the init_module syscall to have any PATH
> > records associated with it, so when a few of them had hundreds or more
> > this wa
On 2017-03-07 11:20, Steven Rostedt wrote:
> On Tue, 7 Mar 2017 11:00:27 -0500
> Richard Guy Briggs <r...@redhat.com> wrote:
>
> > On 2017-03-07 10:41, Steven Rostedt wrote:
> > > On Mon, 6 Mar 2017 22:39:54 -0500
> > > Richard Guy Briggs <r...@redhat.com
On 2017-03-07 11:20, Steven Rostedt wrote:
> On Tue, 7 Mar 2017 11:00:27 -0500
> Richard Guy Briggs wrote:
>
> > On 2017-03-07 10:41, Steven Rostedt wrote:
> > > On Mon, 6 Mar 2017 22:39:54 -0500
> > > Richard Guy Briggs wrote:
> > >
> >
On 2017-03-07 10:41, Steven Rostedt wrote:
> On Mon, 6 Mar 2017 22:39:54 -0500
> Richard Guy Briggs <r...@redhat.com> wrote:
>
> > >From the output I've seen, it doesn't look particularly useful, but it
> > was useful to finally see the source of those huge number
On 2017-03-07 10:41, Steven Rostedt wrote:
> On Mon, 6 Mar 2017 22:39:54 -0500
> Richard Guy Briggs wrote:
>
> > >From the output I've seen, it doesn't look particularly useful, but it
> > was useful to finally see the source of those huge numbers of PATH
> &
On 2017-03-07 09:29, Paul Moore wrote:
> On Mon, Mar 6, 2017 at 11:03 PM, Richard Guy Briggs <r...@redhat.com> wrote:
> > On 2017-03-06 10:10, Cong Wang wrote:
> >> On Mon, Mar 6, 2017 at 2:54 AM, Dmitry Vyukov <dvyu...@google.com> wrote:
> >> > Hello,
601 - 700 of 2017 matches
Mail list logo
