Why is syscall auditing on with no rules?

On a stock Fedora installation: $ sudo auditctl -l No rules Nonetheless TIF_SYSCALL_AUDIT is set and the __audit_syscall_entry and __audit_syscall_exit account for 20% of syscall overhead according to perf. This sucks. Unless I'm missing something, syscall auditing is *off*. How hard would it

[PATCH] audit: Only use the syscall slowpath when syscall audit rules exist

...@redhat.com Signed-off-by: Andy Lutomirski l...@amacapital.net --- This is not the best-tested patch in the world. Someone who actually knows how to use syscall auditing should probably give it a spin. It fixes an IMO huge performance issue, though. include/linux/audit.h | 9 +-- kernel

[PATCH v2.1] audit: Only use the syscall slowpath when syscall audit rules exist

...@redhat.com Signed-off-by: Andy Lutomirski l...@amacapital.net --- This brown paper bag release is brought to you by git commit's -a flag. Changes from v2: Contains the correct patch Changes from v1: - For new tasks, set flags in a new audit_sync_flags callback instead of in audit_alloc (thanks, Oleg

[PATCH v2] audit: Only use the syscall slowpath when syscall audit rules exist

...@redhat.com Signed-off-by: Andy Lutomirski l...@amacapital.net --- Changes from v1: - For new tasks, set flags in a new audit_sync_flags callback instead of in audit_alloc (thanks, Oleg). - Rework locking. - Use irqsave/irqrestore to avoid having to think about who else might have taken spinlocks

Re: [PATCH] audit: Only use the syscall slowpath when syscall audit rules exist

On Mon, Feb 3, 2014 at 12:23 PM, Steve Grubb sgr...@redhat.com wrote: On Monday, February 03, 2014 09:53:23 AM Andy Lutomirski wrote: This toggles TIF_SYSCALL_AUDIT as needed when rules change instead of leaving it set whenever rules might be set in the future. This reduces syscall latency

Re: [PATCH v2.1] audit: Only use the syscall slowpath when syscall audit rules exist

On Tue, Feb 4, 2014 at 8:50 AM, Oleg Nesterov o...@redhat.com wrote: On 02/03, Andy Lutomirski wrote: +void audit_inc_n_rules() +{ + struct task_struct *p, *g; + unsigned long flags; + + read_lock_irqsave(tasklist_lock, flags); Confused... read_lock(tasklist) doesn't need

Re: [PATCH v2.1] audit: Only use the syscall slowpath when syscall audit rules exist

On Tue, Feb 4, 2014 at 11:11 AM, Oleg Nesterov o...@redhat.com wrote: On 02/04, Andy Lutomirski wrote: On Tue, Feb 4, 2014 at 8:50 AM, Oleg Nesterov o...@redhat.com wrote: On 02/03, Andy Lutomirski wrote: Sorry, forgot to mention: where is this mythical for_each_process_thread? In Linus's

[ARCH question] Do syscall_get_nr and syscall_get_arguments always work?

On Tue, Feb 4, 2014 at 11:32 AM, Andy Lutomirski l...@amacapital.net wrote: Now we get rid of __audit_syscall_entry. (This speeds up even the auditing-is-on case.) Instead we have __audit_start_record, which does more or less the same thing, except that (a) it doesn't BUG if in_syscall

[PATCH v3] audit: Turn off TIF_SYSCALL_AUDIT when there are no rules

be more code. Cc: Oleg Nesterov o...@redhat.com Cc: Steve Grubb sgr...@redhat.com Cc: Eric Paris epa...@redhat.com Signed-off-by: Andy Lutomirski l...@amacapital.net --- Changes from v2 (actually v2.1): - Use for_each_process_thread instead of do_each_thread :) - Turn off TIF_SYSCALL_AUDIT lazily

Re: [PATCH v3] audit: Turn off TIF_SYSCALL_AUDIT when there are no rules

On Mon, Feb 10, 2014 at 8:57 AM, Oleg Nesterov o...@redhat.com wrote: On 02/08, Andy Lutomirski wrote: +void audit_inc_n_rules() +{ + struct task_struct *p, *t; + + read_lock(tasklist_lock); + audit_n_rules++; + smp_wmb(); + if (audit_n_rules == 1

Re: [ARCH question] Do syscall_get_nr and syscall_get_arguments always work?

On Tue, Feb 18, 2014 at 11:39 AM, Eric Paris epa...@redhat.com wrote: On Fri, 2014-02-07 at 08:40 -0800, Andy Lutomirski wrote: On Fri, Feb 7, 2014 at 4:58 AM, Jonas Bonn jonas.b...@gmail.com wrote: Hi Andy, On 5 February 2014 00:50, Andy Lutomirski l...@amacapital.net wrote: I can't

Re: [PATCH v2 2/2] audit: Mark CONFIG_AUDITSYSCALL BROKEN and update help text

On Wed, May 28, 2014 at 7:54 PM, Eric Paris epa...@redhat.com wrote: On Wed, 2014-05-28 at 19:40 -0700, Andy Lutomirski wrote: On Wed, May 28, 2014 at 7:09 PM, Eric Paris epa...@redhat.com wrote: NAK On Wed, 2014-05-28 at 18:44 -0700, Andy Lutomirski wrote: Here are some issues

[PATCH v2 2/2] audit: Mark CONFIG_AUDITSYSCALL BROKEN and update help text

. - Its approach to freeing memory is terrifying. Signed-off-by: Andy Lutomirski l...@amacapital.net --- init/Kconfig | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 9d3585b..24d4b53 100644 --- a/init/Kconfig +++ b/init/Kconfig

Re: [PATCH v2 1/2] auditsc: audit_krule mask accesses need bounds checking

On Wed, May 28, 2014 at 7:43 PM, Eric Paris epa...@redhat.com wrote: On Wed, 2014-05-28 at 19:27 -0700, Andy Lutomirski wrote: On Wed, May 28, 2014 at 7:23 PM, Eric Paris epa...@redhat.com wrote: On Wed, 2014-05-28 at 18:44 -0700, Andy Lutomirski wrote: Fixes an easy DoS and possible

[PATCH v2 0/2] Fix auditsc DoS and mark it BROKEN

CONFIG_AUDITSYSCALL is awful. Patch 2 enumerates some reasons. Patch 1 fixes a nasty DoS and possible information leak. It should be applied and backported. Patch 2 is optional. I leave it to other peoples' judgment. Andy Lutomirski (2): auditsc: audit_krule mask accesses need bounds

Re: [PATCH v2 1/2] auditsc: audit_krule mask accesses need bounds checking

On Wed, May 28, 2014 at 7:23 PM, Eric Paris epa...@redhat.com wrote: On Wed, 2014-05-28 at 18:44 -0700, Andy Lutomirski wrote: Fixes an easy DoS and possible information disclosure. This does nothing about the broken state of x32 auditing. Cc: sta...@vger.kernel.org Signed-off-by: Andy

Re: [PATCH v2 2/2] audit: Mark CONFIG_AUDITSYSCALL BROKEN and update help text

On Wed, May 28, 2014 at 7:09 PM, Eric Paris epa...@redhat.com wrote: NAK On Wed, 2014-05-28 at 18:44 -0700, Andy Lutomirski wrote: Here are some issues with the code: - It thinks that syscalls have four arguments. Not true at all. It records the registers that would hold the first 4

Re: [PATCH v2 2/2] audit: Mark CONFIG_AUDITSYSCALL BROKEN and update help text

On Thu, May 29, 2014 at 6:05 AM, Steve Grubb sgr...@redhat.com wrote: On Wednesday, May 28, 2014 07:40:57 PM Andy Lutomirski wrote: - It assumes that syscall numbers are between 0 and 2048. There could well be a bug here. Not questioning that. Although that would be patch 1/2 Even

Re: [PATCH v2 2/2] audit: Mark CONFIG_AUDITSYSCALL BROKEN and update help text

On Thu, May 29, 2014 at 9:25 AM, Steve Grubb sgr...@redhat.com wrote: On Thursday, May 29, 2014 09:04:10 AM Andy Lutomirski wrote: On Thu, May 29, 2014 at 6:05 AM, Steve Grubb sgr...@redhat.com wrote: On Wednesday, May 28, 2014 07:40:57 PM Andy Lutomirski wrote: - It assumes that syscall

[PATCH 2/2] audit: Syscall auditing lite

fields (arch, syscall, and a0..a5) will only be logged if we are in a syscall but we aren't otherwise building an auditsc context. This is only supported on x86 for now. Other architectures can get this if they implement syscall_in_syscall. Signed-off-by: Andy Lutomirski l...@amacapital.net

[PATCH 0/2] Syscall auditing lite

think. Andy Lutomirski (2): x86,syscall: Add syscall_in_syscall to test whether we're in a syscall audit: Syscall auditing lite arch/x86/Kconfig | 1 + arch/x86/include/asm/syscall.h | 21 init/Kconfig | 3 +++ kernel/audit.c

[PATCH 1/2] x86, syscall: Add syscall_in_syscall to test whether we're in a syscall

syscall_in_syscall will return true if we're in a real syscall and will return false if we're not in a syscall. If we're in a bad syscall, the return value can vary. The idea is to use this to come up with a much simpler replacement for syscall auditing. Signed-off-by: Andy Lutomirski l

Re: [PATCH 1/2] x86,syscall: Add syscall_in_syscall to test whether we're in a syscall

On May 30, 2014 2:58 PM, Andy Lutomirski l...@amacapital.net wrote: syscall_in_syscall will return true if we're in a real syscall and will return false if we're not in a syscall. If we're in a bad syscall, the return value can vary. The idea is to use this to come up with a much simpler

Re: [PATCH 1/2] auditsc: audit_krule mask accesses need bounds checking

On Mon, Jun 9, 2014 at 3:30 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, May 28, 2014 at 11:09:58PM -0400, Eric Paris wrote: From: Andy Lutomirski l...@amacapital.net Fixes an easy DoS and possible information disclosure. This does nothing about the broken state of x32 auditing

Re: [PATCH 1/2] auditsc: audit_krule mask accesses need bounds checking

On Mon, Jun 9, 2014 at 3:53 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Jun 9, 2014 at 3:35 PM, Andy Lutomirski l...@amacapital.net wrote: Hmm. It seems that it didn't make it into Linus' tree. Crap. I assume that if there is a maintainer who normally sends me stuff

[GIT PULL] CVE-2014-3917

) Andy Lutomirski (1): auditsc: audit_krule mask accesses need bounds checking kernel/auditsc.c | 27 ++- 1 file changed, 18 insertions(+), 9 deletions(-) NB: This is exactly the same patch that's been on the list, except that I added

Re: [PATCH 1/2] auditsc: audit_krule mask accesses need bounds checking

On Mon, Jun 9, 2014 at 3:46 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Jun 09, 2014 at 03:35:02PM -0700, Andy Lutomirski wrote: On Mon, Jun 9, 2014 at 3:30 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, May 28, 2014 at 11:09:58PM -0400, Eric Paris wrote: From: Andy

Re: [PATCH 1/2] auditsc: audit_krule mask accesses need bounds checking

On Mon, Jun 9, 2014 at 5:32 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Jun 09, 2014 at 03:55:20PM -0700, Andy Lutomirski wrote: On Mon, Jun 9, 2014 at 3:46 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Jun 09, 2014 at 03:35:02PM -0700, Andy Lutomirski wrote: On Mon, Jun 9

Fwd: 3.15: kernel BUG at kernel/auditsc.c:1525!

Steve Grubb pointed out that I forgot to cc: linux-audit. --Andy -- Forwarded message -- From: Andy Lutomirski l...@amacapital.net Date: Mon, Jun 16, 2014 at 2:35 PM Subject: Re: 3.15: kernel BUG at kernel/auditsc.c:1525! To: Richard Weinberger rich...@nod.at, H. Peter Anvin h

Re: [PATCH V4 1/8] namespaces: assign each namespace instance a serial number

On Aug 20, 2014 8:12 PM, Richard Guy Briggs r...@redhat.com wrote: Generate and assign a serial number per namespace instance since boot. Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change

Re: [PATCH V4 3/8] namespaces: expose ns instance serial numbers in proc

On Aug 20, 2014 8:12 PM, Richard Guy Briggs r...@redhat.com wrote: Expose the namespace instace serial numbers in the proc filesystem at /proc/pid/ns/ns_snum. The link text gives the serial number in hex. What's the use case? I understand the utility of giving unique numbers to the audit

Re: [PATCH V4 1/8] namespaces: assign each namespace instance a serial number

On Thu, Aug 21, 2014 at 2:28 PM, Richard Guy Briggs r...@redhat.com wrote: On 14/08/21, Andy Lutomirski wrote: On Aug 20, 2014 8:12 PM, Richard Guy Briggs r...@redhat.com wrote: Generate and assign a serial number per namespace instance since boot. Use a serial number per namespace

Re: [PATCH V4 3/8] namespaces: expose ns instance serial numbers in proc

On Thu, Aug 21, 2014 at 6:58 PM, Richard Guy Briggs r...@redhat.com wrote: On 14/08/21, Andy Lutomirski wrote: On Aug 20, 2014 8:12 PM, Richard Guy Briggs r...@redhat.com wrote: Expose the namespace instace serial numbers in the proc filesystem at /proc/pid/ns/ns_snum. The link text gives

Re: [PATCH V4 3/8] namespaces: expose ns instance serial numbers in proc

On Mon, Aug 25, 2014 at 8:43 AM, Nicolas Dichtel nicolas.dich...@6wind.com wrote: Le 25/08/2014 16:04, Andy Lutomirski a écrit : On Aug 25, 2014 6:30 AM, Nicolas Dichtel nicolas.dich...@6wind.com wrote: CRIU wants to save the complete state of a namespace and then restore

Re: [PATCH V4 3/8] namespaces: expose ns instance serial numbers in proc

On Mon, Aug 25, 2014 at 9:41 AM, Nicolas Dichtel nicolas.dich...@6wind.com wrote: Le 25/08/2014 18:13, Andy Lutomirski a écrit : On Mon, Aug 25, 2014 at 8:43 AM, Nicolas Dichtel nicolas.dich...@6wind.com wrote: Le 25/08/2014 16:04, Andy Lutomirski a écrit : On Aug 25, 2014 6:30 AM, Nicolas

Re: [PATCH V4 3/8] namespaces: expose ns instance serial numbers in proc

On Aug 25, 2014 6:30 AM, Nicolas Dichtel nicolas.dich...@6wind.com wrote: CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange

Re: Regression: audit: x86: drop arch from __audit_syscall_entry() interface

On 10/22/2014 11:23 AM, Eric Paris wrote: That's really serious. Looking now. On Wed, 2014-10-22 at 16:08 -0200, Paulo Zanoni wrote: Hi (Cc'ing everybody mentioned in the original patch) I work for Intel, on our Linux Graphics driver - aka i915.ko - and our QA team recently reported a

Re: Regression: audit: x86: drop arch from __audit_syscall_entry() interface

On Wed, Oct 22, 2014 at 12:16 PM, Richard Guy Briggs r...@redhat.com wrote: On 14/10/22, Andy Lutomirski wrote: On 10/22/2014 11:23 AM, Eric Paris wrote: That's really serious. Looking now. On Wed, 2014-10-22 at 16:08 -0200, Paulo Zanoni wrote: Hi (Cc'ing everybody mentioned

Re: [PATCH] i386/audit: stop scribbling on the stack frame

On 10/22/2014 09:04 PM, Eric Paris wrote: git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb. It was writing over %esp/pt_regs semi-randomly on i686 with the expected system can't boot results. As noted in: https://bugs.freedesktop.org/show_bug.cgi?id=85277 This

Re: [PATCH] i386/audit: stop scribbling on the stack frame

On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris epa...@redhat.com wrote: On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote: On 10/22/2014 09:04 PM, Eric Paris wrote: git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb. It was writing over %esp/pt_regs semi-randomly

Re: [PATCH] i386/audit: stop scribbling on the stack frame

On Thu, Oct 23, 2014 at 12:30 PM, Eric Paris epa...@redhat.com wrote: On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote: On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris epa...@redhat.com wrote: On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote: On 10/22/2014 09:04 PM, Eric Paris

Re: [PATCH] i386/audit: stop scribbling on the stack frame

the confusion comes from. And, by the time you get to sysenter_do_call, nothing cares about ecx, so you can freely clobber it while popping from the stack. I get it now. --Andy -hpa -- Andy Lutomirski AMA Capital Management, LLC -- Linux-audit mailing list Linux-audit@redhat.com https

Re: [PATCH] powerpc: add little endian flag to syscall_get_arch()

(EM_S390|__AUDIT_ARCH_64BIT) #define AUDIT_ARCH_SH (EM_SH) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-api in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Andy Lutomirski AMA

Re: x32 + audit status?

On Mar 5, 2015 10:32 AM, David Drysdale drysd...@google.com wrote: Hi, Do we currently expect the audit system to work with x32 syscalls? I was playing with the audit system for the first time today (on v4.0-rc2, due to [1]), and it didn't seem to work for me. (Tweaking ptrace.c like the

Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances

On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs r...@redhat.com wrote: On 15/05/14, Paul Moore wrote: * Look at our existing audit records to determine which records should have namespace and container ID tokens added. We may only want to add the additional fields in the case where the

Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances

On May 15, 2015 9:38 PM, Steve Grubb sgr...@redhat.com wrote: On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote: On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs r...@redhat.com wrote: On 15/05/14, Paul Moore wrote: * Look at our existing audit records to determine which

Should audit_seccomp check audit_enabled?

by journald but switched off, I think that the records shouldn't be emitted. If you agree, I can send the two-line patch. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit

Re: Should audit_seccomp check audit_enabled?

chromium.org> wrote: >>> > On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <l...@amacapital.net> >> wrote: >>> >> I would argue that, if auditing is off, audit_seccomp shouldn't do >>> >> anything. After all, unlike e.g. selinux, seccom

Re: Should audit_seccomp check audit_enabled?

On Oct 23, 2015 10:01 AM, "Kees Cook" <keesc...@chromium.org> wrote: > > On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <l...@amacapital.net> wrote: > > I would argue that, if auditing is off, audit_seccomp shouldn't do > > anything. After all, unlike e

Re: Should audit_seccomp check audit_enabled?

On Fri, Oct 23, 2015 at 2:22 PM, Kees Cook <keesc...@chromium.org> wrote: > On Fri, Oct 23, 2015 at 2:07 PM, Andy Lutomirski <l...@amacapital.net> wrote: >> On Oct 23, 2015 10:01 AM, "Kees Cook" <keesc...@chromium.org> wrote: >>> >>&

Re: [PATCH v3 1/4] seccomp: Add sysctl to display available actions

On Mon, Feb 13, 2017 at 7:45 PM, Tyler Hicks wrote: > This patch creates a read-only sysctl containing an ordered list of > seccomp actions that the kernel supports. The ordering, from left to > right, is the lowest action value (kill) to the highest action value > (allow).

Re: [PATCH v3 0/4] Improved seccomp logging

On Thu, Feb 16, 2017 at 3:29 PM, Kees Cook <keesc...@chromium.org> wrote: > On Wed, Feb 15, 2017 at 7:24 PM, Andy Lutomirski <l...@amacapital.net> wrote: >> On Mon, Feb 13, 2017 at 7:45 PM, Tyler Hicks <tyhi...@canonical.com> wrote: >>> This patch set is the

Re: [PATCH v3 0/4] Improved seccomp logging

On Mon, Feb 13, 2017 at 7:45 PM, Tyler Hicks wrote: > This patch set is the third revision of the following two previously > submitted patch sets: > > v1: > http://lkml.kernel.org/r/1483375990-14948-1-git-send-email-tyhi...@canonical.com > v1: >

Re: [PATCH v3 1/4] seccomp: Add sysctl to display available actions

On Thu, Feb 16, 2017 at 10:47 AM, Tyler Hicks <tyhi...@canonical.com> wrote: > On 02/15/2017 09:14 PM, Andy Lutomirski wrote: >> On Mon, Feb 13, 2017 at 7:45 PM, Tyler Hicks <tyhi...@canonical.com> wrote: >>> This patch creates a read-only sysctl containing an order

Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions

On Mon, Jan 2, 2017 at 8:53 AM, Tyler Hicks wrote: > This patch set creates the basis for auditing information specific to a given > seccomp return action and then starts auditing SECCOMP_RET_ERRNO return > actions. The audit messages for SECCOMP_RET_ERRNO return actions

Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions

On Mon, Jan 2, 2017 at 2:47 PM, Paul Moore wrote: > On Mon, Jan 2, 2017 at 11:53 AM, Tyler Hicks wrote: >> This patch set creates the basis for auditing information specific to a given >> seccomp return action and then starts auditing SECCOMP_RET_ERRNO

Re: [PATCH v3 0/4] Improved seccomp logging

On Fri, Apr 7, 2017 at 3:16 PM, Tyler Hicks <tyhi...@canonical.com> wrote: > On 02/22/2017 12:46 PM, Kees Cook wrote: >> On Thu, Feb 16, 2017 at 3:29 PM, Kees Cook <keesc...@chromium.org> wrote: >>> On Wed, Feb 15, 2017 at 7:24 PM, Andy Lutomirski <l...@amacapital.

Re: [PATCH v3 0/4] Improved seccomp logging

On Mon, May 1, 2017 at 7:41 PM, Tyler Hicks wrote: > On 04/27/2017 07:42 PM, Kees Cook wrote: >> On Thu, Apr 27, 2017 at 3:17 PM, Tyler Hicks wrote: >>> Quick update... I finished the move from the high-water mark >>> log_max_action sysctl to the

Re: [PATCH V3 05/10] capabilities: use intuitive names for id changes

On Wed, Aug 23, 2017 at 3:12 AM, Richard Guy Briggs wrote: > 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 > --- > security/commoncap.c | 26

Re: [PATCH V3 05/10] capabilities: use intuitive names for id changes

--Andy > On Aug 25, 2017, at 11:51 AM, Serge E. Hallyn <se...@hallyn.com> wrote: > > Quoting Andy Lutomirski (l...@kernel.org): >>> On Wed, Aug 23, 2017 at 3:12 AM, Richard Guy Briggs <r...@redhat.com> wrote: >>> Introduce a number of inlines to mak

Re: [PATCH V3 07/10] capabilities: remove a layer of conditional logic

On Wed, Aug 23, 2017 at 3:12 AM, Richard Guy Briggs wrote: > Remove a layer of conditional logic to make the use of conditions > easier to read and analyse. > > Signed-off-by: Richard Guy Briggs > --- > security/commoncap.c | 13 ++--- > 1 files

Re: [PATCH 00/18] xfrm: Add compat layer

> On Jul 27, 2018, at 9:48 AM, Nathan Harold wrote: > > We (Android) are very interested in removing the restriction for 32-bit > userspace processes accessing xfrm netlink on 64-bit kernels. IPsec support > is required to pass Android conformance tests, and any manufacturer wishing > to

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

On Sat, Mar 10, 2018 at 10:15 AM, Steve Grubb wrote: > On Wed, 7 Mar 2018 18:43:42 -0500 > Paul Moore wrote: >> ... and I just realized that linux-audit isn't on the To/CC line, >> adding them now. >> >> Link to the patch is below. >> >> *

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

On Wed, Mar 14, 2018 at 12:28 AM, Jiri Kosina <ji...@kernel.org> wrote: > On Wed, 14 Mar 2018, Andy Lutomirski wrote: > >> > Yes...I wished I was in on the beginning of this discussion. Here's the >> > problem. We need all tasks auditable unless specifically d

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

On Wed, Mar 7, 2018 at 11:41 PM, Paul Moore <p...@paul-moore.com> wrote: > On Wed, Mar 7, 2018 at 11:48 AM, Jiri Kosina <ji...@kernel.org> wrote: >> On Wed, 7 Mar 2018, Andy Lutomirski wrote: >>> Wow, this was a long time ago. >> >> Oh yeah; but it now r

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

i...@kernel.org> wrote: >>>>> On Wed, 7 Mar 2018, Andy Lutomirski wrote: >>>>> Wow, this was a long time ago. >>>> >>>> Oh yeah; but it now resurfaced on our side, as we are of course receiving >>>> a lot of requests with respect

Re: [PATCH 2/2] RISC-V: Add support for SECCOMP

On Wed, Oct 24, 2018 at 2:42 PM Kees Cook wrote: > > On Wed, Oct 24, 2018 at 1:40 PM, Palmer Dabbelt wrote: > > From: "Wesley W. Terpstra" > > > > This is a fairly straight-forward implementation of seccomp for RISC-V > > systems. > > > > Signed-off-by: Wesley W. Terpstra > > Signed-off-by:

Re: [PATCH 06/13] arc: define syscall_get_arch()

> On Nov 9, 2018, at 8:50 AM, Vineet Gupta wrote: > >> On 11/8/18 7:16 PM, Dmitry V. Levin wrote: >> syscall_get_arch() is required to be implemented on all architectures >> that use tracehook_report_syscall_entry() in order to extend >> the generic ptrace API with PTRACE_GET_SYSCALL_INFO

Re: [PATCH 00/13] Prepare for PTRACE_GET_SYSCALL_INFO

On Thu, Nov 8, 2018 at 7:13 PM Dmitry V. Levin wrote: > > syscall_get_arch() is required to be implemented on all architectures > that use tracehook_report_syscall_entry() in order to extend > the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. Nice! I'm pretty sure you have vastly

Re: [PATCH 06/13] arc: define syscall_get_arch()

On Fri, Nov 9, 2018 at 6:22 AM Alexey Brodkin wrote: > > Hi Dmitry, > > On Fri, 2018-11-09 at 06:16 +0300, Dmitry V. Levin wrote: > > syscall_get_arch() is required to be implemented on all architectures > > that use tracehook_report_syscall_entry() in order to extend > > the generic ptrace API

Re: [PATCH 06/13] arc: define syscall_get_arch()

> On Nov 9, 2018, at 7:27 AM, Alexey Brodkin > wrote: > > Hi Andy, > >> On Fri, 2018-11-09 at 07:17 -0800, Andy Lutomirski wrote: >> On Fri, Nov 9, 2018 at 6:22 AM Alexey Brodkin >> wrote: >>> Hi Dmitry, >>> >>&g

Re: [PATCH 06/13] arc: define syscall_get_arch()

On Fri, Nov 9, 2018 at 8:11 AM Alexey Brodkin wrote: > > Hi Andy, > > On Fri, 2018-11-09 at 07:56 -0800, Andy Lutomirski wrote: > > > On Nov 9, 2018, at 7:27 AM, Alexey Brodkin > > > wrote: > > > > > > Hi Andy, > > > > &g

Re: [PATCH v2 16/15] syscall_get_arch: add "struct task_struct *" argument

their argument. > > This change partially reverts commit 5e937a9ae913 ("syscall_get_arch: > remove useless function arguments"). > Reviewed-by: Andy Lutomirski # for x86 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH 00/34] fs: idmapped mounts

On Fri, Oct 30, 2020 at 5:02 AM Christian Brauner wrote: > > On Thu, Oct 29, 2020 at 02:58:55PM -0700, Andy Lutomirski wrote: > > > > > > > On Oct 28, 2020, at 5:35 PM, Christian Brauner > > > wrote: > > > > > > Hey everyone, > > >

Re: [PATCH 00/34] fs: idmapped mounts

> On Oct 28, 2020, at 5:35 PM, Christian Brauner > wrote: > > Hey everyone, > > I vanished for a little while to focus on this work here so sorry for > not being available by mail for a while. > > Since quite a long time we have issues with sharing mounts between > multiple unprivileged