On Tue, Oct 31, 2023 at 5:24 PM Steve Grubb wrote:
>
> Hello,
>
> I think the linux-audit mail list will be shutdown at midnight tonight ...
Whoa, that seems rather abrupt, is the mail server being shut down?
Or something else?
> There are mail archives such as
>
>
On Thu, Aug 31, 2023 at 5:33 AM Liu, Yujie wrote:
> On Wed, 2023-08-30 at 10:29 -0400, Paul Moore wrote:
> > I have no idea if there is a person attached to any of the addresses
> > on the To line above, but please send audit kernel issues to
> > au...@vger.kernel.or
r: nf_tables: Introduce NFT_MSG_GETRULE_RESET")
> Signed-off-by: Phil Sutter
> ---
> include/linux/audit.h | 1 +
> kernel/auditsc.c | 1 +
> net/netfilter/nf_tables_api.c | 18 ++
> 3 files changed, 20 insertions(+)
See my comments in patch 1
out
during the first few days of the merge window it might be advisable to
wait more than a day or two to give the relevant maintainers a chance
to review the patch.
Also, as a note for future submissions, we've moved the audit kernel
mailing list to au...@vger.kernel.org.
Acked-by: Paul Moo
On Wed, Aug 30, 2023 at 12:17 AM kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git main
> head: 94e5ef9b157c6c3779352a8d4121542f71de52a1
> commit: 94e5ef9b157c6c3779352a8d4121542f71de52a1 [1/1] audit: add a Linux
> Audit specific README.md and
On August 26, 2023 2:38:55 AM Tetsuo Handa
wrote:
On 2023/08/25 12:36, Paul Moore wrote:
It is unfortunate that you continue ignoring the
How can auditd generate logs that are not triggered via syscalls?
line. I know how to configure syscall rules using "-S" option. But I do
no
On August 24, 2023 6:24:47 PM Tetsuo Handa
wrote:
On 2023/08/24 23:26, Paul Moore wrote:
On Thu, Aug 24, 2023 at 9:47 AM Tetsuo Handa
wrote:
On 2023/08/24 22:39, Tetsuo Handa wrote:
(1) Catch _all_ process creations (both via fork()/clone() system calls and
kthread_create() from the kernel
On Thu, Aug 24, 2023 at 11:55 AM Steve Grubb wrote:
> On Thursday, August 24, 2023 9:30:10 AM EDT Paul Moore wrote:
> > On Thu, Aug 24, 2023 at 9:21 AM Tetsuo Handa
> > wrote:
> > > On 2023/08/23 23:48, Paul Moore wrote:
> > > > We've already discussed this
On Thu, Aug 24, 2023 at 9:47 AM Tetsuo Handa
wrote:
> On 2023/08/24 22:39, Tetsuo Handa wrote:
> >>> (1) Catch _all_ process creations (both via fork()/clone() system calls
> >>> and
> >>> kthread_create() from the kernel), and duplicate the history upon
> >>> process
> >>>
On Thu, Aug 24, 2023 at 9:39 AM Tetsuo Handa
wrote:
> On 2023/08/24 22:30, Paul Moore wrote:
> > On Thu, Aug 24, 2023 at 9:21 AM Tetsuo Handa
> > wrote:
> >>
> >> On 2023/08/23 23:48, Paul Moore wrote:
> >>> We've already discussed this both fr
On Thu, Aug 24, 2023 at 9:21 AM Tetsuo Handa
wrote:
>
> On 2023/08/23 23:48, Paul Moore wrote:
> > We've already discussed this both from a kernel load perspective (it
> > should be able to handle the load, if not that is a separate problem
> > to address) as well as the h
On Wed, Aug 23, 2023 at 10:18 AM Tetsuo Handa
wrote:
> On 2023/08/22 1:35, Paul Moore wrote:
> >> "auditctl -D" must not clear rules for tracing fork()/execve()/exit()
> >> system calls. This is impossible because this change will break userspace
> >>
On Tue, Aug 22, 2023 at 12:29 PM Steve Grubb wrote:
> On Wednesday, August 16, 2023 9:53:58 AM EDT Paul Moore wrote:
> > On Wed, Aug 16, 2023 at 6:10 AM Tetsuo Handa
> > wrote:
> > > On 2023/08/16 3:44, Paul Moore wrote:
> > > > On Fri, Aug 11, 2023 at
On Sat, Aug 19, 2023 at 3:09 AM Tetsuo Handa
wrote:
> On 2023/08/18 23:59, Paul Moore wrote:
> > Except we are not talking SELinux or LSMs here, we are talking about
> > audit and the audit subsystem is very different from the LSM layer.
> > The LSM layer is designed to be p
On Fri, Aug 18, 2023 at 6:30 AM Tetsuo Handa
wrote:
> On 2023/08/16 22:53, Paul Moore wrote:
> > On Wed, Aug 16, 2023 at 6:10 AM Tetsuo Handa
> > wrote:
> >> On 2023/08/16 3:44, Paul Moore wrote:
> >>> On Fri, Aug 11, 2023 at 6:58 AM Tetsuo Handa
> >&
On Wed, Aug 16, 2023 at 6:10 AM Tetsuo Handa
wrote:
> On 2023/08/16 3:44, Paul Moore wrote:
> > On Fri, Aug 11, 2023 at 6:58 AM Tetsuo Handa
> > wrote:
> >>
> >> When an unexpected system event occurs, the administrator may want to
> >> identify which ap
On Fri, Aug 11, 2023 at 6:58 AM Tetsuo Handa
wrote:
>
> When an unexpected system event occurs, the administrator may want to
> identify which application triggered the event. For example, unexpected
> process termination is still a real concern enough to write articles
> like
On Tue, Aug 8, 2023 at 6:07 AM Tetsuo Handa
wrote:
> On 2023/08/08 5:13, Paul Moore wrote:
> > On Mon, Aug 7, 2023 at 3:03 PM Steve Grubb wrote:
> >> On Monday, August 7, 2023 2:53:40 PM EDT Paul Moore wrote:
> >>> On Sun, Aug 6, 2023 at 9:05 AM Tetsuo Handa
&
On Mon, Aug 7, 2023 at 3:03 PM Steve Grubb wrote:
> On Monday, August 7, 2023 2:53:40 PM EDT Paul Moore wrote:
> > On Sun, Aug 6, 2023 at 9:05 AM Tetsuo Handa
> >
> > wrote:
> > > When an unexpected system event occurs, the administrator may want to
> > &g
On Sun, Aug 6, 2023 at 9:05 AM Tetsuo Handa
wrote:
>
> When an unexpected system event occurs, the administrator may want to
> identify which application triggered the event. For example, unexpected
> process termination is still a real concern enough to write articles
> like
On Tue, Jun 6, 2023 at 3:09 PM Steve Grubb wrote:
> On Tuesday, June 6, 2023 6:31:55 PM EDT Vincent Abraham wrote:
> > Thanks. Could you also point to portions in the codebase where these
> > functions are called for monitoring file access?
>
> I'll let Richard or Paul point to the place in the
On Wed, May 24, 2023 at 10:46 AM Steve Grubb wrote:
> On Wednesday, May 24, 2023 7:37:27 AM EDT Rinat Gadelshin wrote:
> > Hello there.
> >
> > It seems that the kernel doesn't send messages for syscalls of the shell
> > process from which auditd is installed.
> >
> > Reproducing steps (performed
On Wed, May 3, 2023 at 10:50 PM Tetsuo Handa
wrote:
> On 2023/05/04 7:12, Rinat Gadelshin wrote:
> > On 04.05.2023 00:27, Paul Moore wrote:
> >> Can you be more specific about the kernel threads you are seeing, are
> >> you seeing multiple "kauditd" threads
On Wed, May 3, 2023 at 5:14 PM Rinat Gadelshin wrote:
> Hello there =)
>
> My name is Rinat.
> I'm a newbie here (at Linux kernel developer community).
>
> My current job is to work with audit subsystem on different
> versions of Linux (and different kernel versions from 3.10 to the latest)
>
On Fri, Apr 28, 2023 at 8:25 AM 江杨 wrote:
>
> May I ask if Auditd supports Docker? Thank you
> https://listman.redhat.com/archives/linux-audit/2018-July/msg00078.html
Have you tried the configuration changes suggested in the mailing list
post you linked above?
--
paul-moore.com
--
Linux-audit
On Mon, Apr 17, 2023 at 5:18 PM Fan Wu wrote:
> On Mon, Apr 17, 2023 at 04:16:29PM -0400, Paul Moore wrote:
> > On Mon, Apr 17, 2023 at 2:06???PM Fan Wu wrote:
> > > On Thu, Apr 13, 2023 at 02:45:07PM -0400, Paul Moore wrote:
> > > > On Wed, Apr 12, 2023 at 7:
On Mon, Apr 17, 2023 at 2:06 PM Fan Wu wrote:
> On Thu, Apr 13, 2023 at 02:45:07PM -0400, Paul Moore wrote:
> > On Wed, Apr 12, 2023 at 7:36???PM Fan Wu wrote:
> > > On Tue, Apr 11, 2023 at 05:45:41PM -0400, Paul Moore wrote:
> > > > On Mon, Apr 10, 2023 at 3:
On Wed, Apr 12, 2023 at 7:36 PM Fan Wu wrote:
> On Tue, Apr 11, 2023 at 05:45:41PM -0400, Paul Moore wrote:
> > On Mon, Apr 10, 2023 at 3:10???PM Fan Wu wrote:
> > > On Thu, Mar 02, 2023 at 02:04:42PM -0500, Paul Moore wrote:
> > > > On Mon, Jan 30, 2023 at 5:
On Thu, Apr 13, 2023 at 12:25 PM Carlos De Avillez
wrote:
>
> Hello again,
>
> Just checking is there is interest in the below.
I noticed that your email ended up in my spam folder, likely because
it was not plaintext, but who knows for sure. You might want to try
posting your patch as a GitHub
On Thu, Mar 2, 2023 at 2:05 PM Paul Moore wrote:
> On Tue, Jan 31, 2023 at 12:11 PM Steve Grubb wrote:
> > On Monday, January 30, 2023 5:57:22 PM EST Fan Wu wrote:
...
> > > audit: MAC_POLICY_LOAD policy_name="dmverity_roothash"
> >
On Thu, Mar 16, 2023 at 6:53 PM Fan Wu wrote:
> On Thu, Mar 02, 2023 at 02:05:33PM -0500, Paul Moore wrote:
> > On Tue, Jan 31, 2023 at 12:11???PM Steve Grubb wrote:
> > >
> > > Hello,
> > >
> > > On Monday, January 30, 2023 5:57:22 PM
On Mon, Apr 10, 2023 at 3:10 PM Fan Wu wrote:
> On Thu, Mar 02, 2023 at 02:04:42PM -0500, Paul Moore wrote:
> > On Mon, Jan 30, 2023 at 5:58???PM Fan Wu wrote:
> > >
> > > From: Deven Bowers
> > >
> > > As is typical with LSMs, IPE uses sec
On Mon, Apr 10, 2023 at 2:53 PM Fan Wu wrote:
> On Thu, Mar 02, 2023 at 02:03:11PM -0500, Paul Moore wrote:
> > On Mon, Jan 30, 2023 at 5:58???PM Fan Wu wrote:
> > >
> > > From: Deven Bowers
> > >
> > > IPE must have a centralized function to evaluat
On Thu, Apr 6, 2023 at 4:00 PM Fan Wu wrote:
> On Thu, Mar 02, 2023 at 02:02:32PM -0500, Paul Moore wrote:
> > On Mon, Jan 30, 2023 at 5:58???PM Fan Wu wrote:
> > >
> > > From: Deven Bowers
> > >
> > > IPE's interpretation of the what the user tr
On Mon, Mar 20, 2023 at 11:09 AM Anurag Aggarwal
wrote:
> >
> > Can you be more specific about the exact repository? There is a
> > repository which contains the development code for the Linux Kernel's
> > audit subsystem, and there is a second repository which contains
> > Steve's audit
On Mon, Mar 20, 2023 at 8:20 AM Anurag Aggarwal
wrote:
>
> Hello All,
>
> Will anyone help me with some documentation on how to build and test
> auditd-kernel repository?
Can you be more specific about the exact repository? There is a
repository which contains the development code for the Linux
On Tue, Mar 7, 2023 at 4:17 PM Steve Grubb wrote:
>
> Hello Paul,
>
> On Tuesday, February 28, 2023 5:04:04 PM EST Paul Moore wrote:
> > ... if you look closely you'll notice that the #289 event (the async
> > URINGOP) is missing from the ausearch output.
>
> Tha
On Fri, Mar 10, 2023 at 9:36 AM Steve Grubb wrote:
>
> On Thursday, March 9, 2023 5:52:28 PM EST Bruce Elrick wrote:
> > Anyway, I think I need to spend some time playing until that "aha!"
> > moment comes. It's feels a lot closer thanks to both of your responses
> > and I really apprecaite the
On Thu, Mar 9, 2023 at 11:33 AM Bruce Elrick wrote:
>
> I think I need to clarify where I'm confused ;-)
>
> With iptables you could write a rule that would only catch system
> calls that were for iptables changes. That is, you didn't need to
> capture *all* setsockopt calls (not that there would
On Wed, Mar 8, 2023 at 7:13 PM Bruce Elrick wrote:
> Hello all,
>
> I'm not sure if this list is appropriate for questions so please let
> me know and otherwise ignore if this message is not appropriate.
>
> I'm trying to help someone who is finally migrating from iptables to
> nftables on the
On Wed, Mar 8, 2023 at 6:53 AM Anurag Aggarwal
wrote:
>> Limiting of audit records is actually done in the kernel, and
>> currently the rate limit applies equally[1] to all records, there is
>> no ability to enforce limits per-key.
>
> One question Paul, will it be ok, if we contribute something
On Tue, Mar 7, 2023 at 4:17 PM Steve Grubb wrote:
>
> Hello Paul,
>
> On Tuesday, February 28, 2023 5:04:04 PM EST Paul Moore wrote:
> > ... if you look closely you'll notice that the #289 event (the async
> > URINGOP) is missing from the ausearch output.
>
> Tha
On Mon, Mar 6, 2023 at 3:58 PM Steve Grubb wrote:
>
> Hello Paul,
>
> On Monday, March 6, 2023 3:07:37 PM EST Paul Moore wrote:
> > On Tue, Feb 28, 2023 at 5:04 PM Paul Moore wrote:
> > > Hi all,
> > >
> > > We just recently started picking up a
On Tue, Feb 28, 2023 at 5:04 PM Paul Moore wrote:
>
> Hi all,
>
> We just recently started picking up audit-testsuite failures with the
> latest upstream kernels and I tracked it down to a change in how the
> IORING_OP_OPENAT operation is handled, and how Steve's audit userspac
On Tue, Jan 31, 2023 at 12:11 PM Steve Grubb wrote:
>
> Hello,
>
> On Monday, January 30, 2023 5:57:22 PM EST Fan Wu wrote:
> > From: Deven Bowers
> >
> > Users of IPE require a way to identify when and why an operation fails,
> > allowing them to both respond to violations of policy and be
On Mon, Jan 30, 2023 at 5:58 PM Fan Wu wrote:
>
> From: Deven Bowers
>
> IPE's interpretation of the what the user trusts is accomplished through
> its policy. IPE's design is to not provide support for a single trust
> provider, but to support multiple providers to enable the end-user to
>
On Mon, Jan 30, 2023 at 5:58 PM Fan Wu wrote:
>
> From: Deven Bowers
>
> IPE, like SELinux, supports a permissive mode. This mode allows policy
> authors to test and evaluate IPE policy without it effecting their
> programs. When the mode is changed, a 1404 AUDIT_MAC_STATUS
> be reported.
>
>
On Mon, Jan 30, 2023 at 5:58 PM Fan Wu wrote:
>
> From: Deven Bowers
>
> block_device structures can have valuable security properties,
> based on how they are created, and what subsystem manages them.
>
> By adding LSM storage to this structure, this data can be accessed
> at the LSM layer.
>
>
On Mon, Jan 30, 2023 at 5:58 PM Fan Wu wrote:
>
> From: Deven Bowers
>
> As is typical with LSMs, IPE uses securityfs as its interface with
> userspace. for a complete list of the interfaces and the respective
> inputs/outputs, please see the documentation under
> admin-guide/LSM/ipe.rst
>
>
On Mon, Jan 30, 2023 at 5:58 PM Fan Wu wrote:
>
> From: Deven Bowers
>
> IPE must have a centralized function to evaluate incoming callers
> against IPE's policy. This iteration of the policy against the rules
> for that specific caller is known as the evaluation loop.
>
> In addition, IPE is
On Fri, Feb 10, 2023 at 6:21 PM Fan Wu wrote:
> On Tue, Jan 31, 2023 at 04:49:44PM +0100, Roberto Sassu wrote:
> > On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote:
> > > From: Deven Bowers
> > >
> > > IPE must have a centralized function to evaluate incoming callers
> > > against IPE's policy.
On Mon, Jan 30, 2023 at 5:58 PM Fan Wu wrote:
>
> From: Deven Bowers
>
> Integrity Policy Enforcement (IPE) is an LSM that provides an
> complimentary approach to Mandatory Access Control than existing LSMs
> today.
>
> Existing LSMs have centered around the concept of access to a resource
>
On Thu, Mar 2, 2023 at 12:24 PM Lenny Bruzenak wrote:
> On 3/1/23 22:13, Anurag Aggarwal wrote:
>>
>> Or if selinux is in force, create policy for the events you definitely want,
>> then look for those types (either subject or object) in your rule. This is
>> something I've seen before, where
Hi all,
We just recently started picking up audit-testsuite failures with the
latest upstream kernels and I tracked it down to a change in how the
IORING_OP_OPENAT operation is handled, and how Steve's audit userspace
displays async io_uring ops. It appears that when ausearch is used to
look for
On Tue, Feb 28, 2023 at 10:35 AM Anurag Aggarwal
wrote:
>
> Hello Paul,
>
> Thank you for your information.
>
>> If you have a particular audit
>> rule which is too verbose *and* you are willing to lose audit records
>> from that filter rule (which is what would happen if they were rate
>>
On Tue, Feb 28, 2023 at 5:53 AM Anurag Aggarwal
wrote:
> Hello All,
>
> The current rate limiter, audit_set_rate_limit limits all types of events. In
> our case, we want to limit auditd events with a specific key, as they are
> very noisy and consume very high CPU.
>
> From my understanding,
(2023-02-07 10:22:29 -0500)
audit/stable-6.3 PR 20230220
Paul Moore (1):
audit: update the mailing list in MAINTAINERS
MAINTAINERS | 2 +-
1 file changed, 1 insertion
On Tue, Feb 14, 2023 at 2:23 PM Paul Moore wrote:
>
> Starting with Steve's audit userspace v3.1, an euid exclude filter no
> longer results in an error. Adjust the test accordingly.
>
> Signed-off-by: Paul Moore
> ---
> tests/filter_exclude/test | 2 +-
> 1 file ch
Starting with Steve's audit userspace v3.1, an euid exclude filter no
longer results in an error. Adjust the test accordingly.
Signed-off-by: Paul Moore
---
tests/filter_exclude/test | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/filter_exclude/test b/tests
On Fri, Feb 10, 2023 at 5:00 PM Richard Guy Briggs wrote:
> On 2023-02-10 11:52, Paul Moore wrote:
> > On Fri, Feb 10, 2023 at 11:00 AM Jens Axboe wrote:
> > > On 2/10/23 8:39?AM, Paul Moore wrote:
> > > > On Thu, Feb 9, 2023 at 7:15 PM Jens Axboe wrote:
> >
On Fri, Feb 10, 2023 at 11:00 AM Jens Axboe wrote:
> On 2/10/23 8:39?AM, Paul Moore wrote:
> > On Thu, Feb 9, 2023 at 7:15 PM Jens Axboe wrote:
> >> On 2/9/23 3:54?PM, Steve Grubb wrote:
> >>> On Thursday, February 9, 2023 5:37:22 PM EST Paul Moore wrote:
> &g
On Thu, Feb 9, 2023 at 7:15 PM Jens Axboe wrote:
> On 2/9/23 3:54 PM, Steve Grubb wrote:
> > On Thursday, February 9, 2023 5:37:22 PM EST Paul Moore wrote:
> >> On Thu, Feb 9, 2023 at 4:53 PM Richard Guy Briggs wrote:
> >>> On 2023-02-01 16:18, Paul Moore wrote:
&
On Thu, Feb 9, 2023 at 5:54 PM Steve Grubb wrote:
> On Thursday, February 9, 2023 5:37:22 PM EST Paul Moore wrote:
> > On Thu, Feb 9, 2023 at 4:53 PM Richard Guy Briggs wrote:
> > > On 2023-02-01 16:18, Paul Moore wrote:
> > > > On Wed, Feb 1, 2023 at 3:34
On Thu, Feb 9, 2023 at 4:53 PM Richard Guy Briggs wrote:
> On 2023-02-01 16:18, Paul Moore wrote:
> > On Wed, Feb 1, 2023 at 3:34 PM Richard Guy Briggs wrote:
> > > fadvise and madvise both provide hints for caching or access pattern for
> > > file and memo
On Wed, Feb 8, 2023 at 12:37 PM Richard Guy Briggs wrote:
> On 2023-02-08 11:24, Paul Moore wrote:
> > On Wed, Feb 8, 2023 at 10:27 AM Steve Grubb wrote:
> > > On Wednesday, February 8, 2023 10:03:24 AM EST Paul Moore wrote:
> > > > On Wed, Feb 8, 2
On Wed, Feb 8, 2023 at 10:27 AM Steve Grubb wrote:
> On Wednesday, February 8, 2023 10:03:24 AM EST Paul Moore wrote:
> > On Wed, Feb 8, 2023 at 7:08 AM Jan Kara wrote:
> > > On Tue 07-02-23 09:54:11, Paul Moore wrote:
> > > > On Tue, Feb 7, 2023 at 7:09 AM Jan Ka
On Wed, Feb 8, 2023 at 7:08 AM Jan Kara wrote:
> On Tue 07-02-23 09:54:11, Paul Moore wrote:
> > On Tue, Feb 7, 2023 at 7:09 AM Jan Kara wrote:
> > > On Fri 03-02-23 16:35:13, Richard Guy Briggs wrote:
> > > > The Fanotify API can be used for access control by reque
On Tue, Feb 7, 2023 at 1:44 PM Paul Moore wrote:
>
> We've moved the upstream Linux Kernel audit subsystem discussions to
> a new mailing list, this patch updates the MAINTAINERS info with the
> new list address.
>
> Marking this for stable inclusion to help speed uptake of the
so the risk should be close to nil.
Cc: sta...@vger.kernel.org
Signed-off-by: Paul Moore
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7f86d02cb427..b686c3af313f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3511,7 +3511,7
On Fri, Feb 3, 2023 at 11:39 AM Paul Moore wrote:
> On Tue, Jan 31, 2023 at 2:44 PM Paul Moore wrote:
> >
> > Hello all,
>
> ...
>
> > I'll hold off on list creation for a couple of days in case anyone has
> > a well reasoned argument against moving upstream
On Tue, Feb 7, 2023 at 7:09 AM Jan Kara wrote:
> On Fri 03-02-23 16:35:13, Richard Guy Briggs wrote:
> > The Fanotify API can be used for access control by requesting permission
> > event notification. The user space tooling that uses it may have a
> > complicated policy that inherently contains
On Tue, Jan 31, 2023 at 2:44 PM Paul Moore wrote:
>
> Hello all,
...
> I'll hold off on list creation for a couple of days in case anyone has
> a well reasoned argument against moving upstream kernel development to
> a new list. However, I want to underscore that any a
On Wed, Feb 1, 2023 at 3:34 PM Richard Guy Briggs wrote:
>
> fadvise and madvise both provide hints for caching or access pattern for
> file and memory respectively. Skip them.
You forgot to update the first sentence in the commit description :/
I'm still looking for some type of statement
Hello all,
Those of you who have been following the linux-audit mailing list
closely over the past several years have likely seen some issues
relating to upstream Linux Kernel development and the mailing list:
disagreements on the focus of the list (upstream vs upstream+distro),
and a moderated
On Sat, Jan 28, 2023 at 12:26 PM Steve Grubb wrote:
> On Friday, January 27, 2023 5:43:02 PM EST Paul Moore wrote:
> > On Fri, Jan 27, 2023 at 12:24 PM Richard Guy Briggs wrote:
> > > Getting XATTRs is not particularly interesting security-wise.
> > >
> > > Su
On Sat, Jan 28, 2023 at 11:48 AM Steve Grubb wrote:
> On Friday, January 27, 2023 5:53:24 PM EST Paul Moore wrote:
> > On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe wrote:
> > > On 1/27/23 3:38 PM, Paul Moore wrote:
> > > > On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe
On Fri, Jan 27, 2023 at 6:01 PM Richard Guy Briggs wrote:
> On 2023-01-27 17:43, Paul Moore wrote:
> > On Fri, Jan 27, 2023 at 12:24 PM Richard Guy Briggs wrote:
> > > Getting XATTRs is not particularly interesting security-wise.
> > >
> > > Suggested-by: St
On Fri, Jan 27, 2023 at 6:02 PM Jens Axboe wrote:
> On 1/27/23 3:53 PM, Paul Moore wrote:
> > On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe wrote:
> >> On 1/27/23 3:38 PM, Paul Moore wrote:
> >>> On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe wrote:
> >>&
On Fri, Jan 27, 2023 at 5:55 PM Richard Guy Briggs wrote:
> On 2023-01-27 17:35, Paul Moore wrote:
> > On Fri, Jan 27, 2023 at 12:24 PM Richard Guy Briggs wrote:
> > >
> > > Since FADVISE can truncate files and MADVISE operates on memory, reverse
> > > th
On Fri, Jan 27, 2023 at 5:45 PM Jens Axboe wrote:
> On 1/27/23 3:35?PM, Paul Moore wrote:
> > On Fri, Jan 27, 2023 at 12:24 PM Richard Guy Briggs wrote:
> >>
> >> Since FADVISE can truncate files and MADVISE operates on memory, reverse
> >> the audit_skip
On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe wrote:
> On 1/27/23 3:38 PM, Paul Moore wrote:
> > On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe wrote:
> >> On 1/27/23 12:42 PM, Paul Moore wrote:
> >>> On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe wrote:
> >>>
On Fri, Jan 27, 2023 at 12:24 PM Richard Guy Briggs wrote:
>
> Getting XATTRs is not particularly interesting security-wise.
>
> Suggested-by: Steve Grubb
> Fixes: a56834e0fafe ("io_uring: add fgetxattr and getxattr support")
> Signed-off-by: Richard Guy Briggs
> ---
> io_uring/opdef.c | 2 ++
On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe wrote:
> On 1/27/23 12:42 PM, Paul Moore wrote:
> > On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe wrote:
> >> On 1/27/23 10:23 AM, Richard Guy Briggs wrote:
> >>> A couple of updates to the iouring ops aud
On Fri, Jan 27, 2023 at 12:24 PM Richard Guy Briggs wrote:
>
> Since FADVISE can truncate files and MADVISE operates on memory, reverse
> the audit_skip tags.
>
> Fixes: 5bd2182d58e9 ("audit,io_uring,io-wq: add some basic audit support to
> io_uring")
> Signed-off-by: Richard Guy Briggs
> ---
>
On Wed, Jan 25, 2023 at 5:11 PM Richard Guy Briggs wrote:
>
> On 2023-01-20 13:58, Paul Moore wrote:
> > On Tue, Jan 17, 2023 at 4:14 PM Richard Guy Briggs wrote:
> > >
> > > This patch passes the full response so that the audit function can use all
> > >
On Wed, Jan 25, 2023 at 5:06 PM Richard Guy Briggs wrote:
> On 2023-01-20 13:52, Paul Moore wrote:
> > On Wed, Jan 18, 2023 at 1:34 PM Steve Grubb wrote:
> > > Hello Richard,
> > >
> > > I built a new kernel and tested this with old and new user space. It is
&
On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe wrote:
> On 1/27/23 10:23 AM, Richard Guy Briggs wrote:
> > A couple of updates to the iouring ops audit bypass selections suggested in
> > consultation with Steve Grubb.
> >
> > Richard Guy Briggs (2):
> > io_uring,audit: audit IORING_OP_FADVISE but
e of fanotify info that is defined is an audit
> rule number, but convert it to hex encoding to future-proof the field.
> Hex encoding suggested by Paul Moore .
>
> The {subj,obj}_trust values are {0,1,2}, corresponding to no, yes, unknown.
>
> Sample records:
> type=FANOTIFY msg=audit
On Wed, Jan 18, 2023 at 1:34 PM Steve Grubb wrote:
>
> Hello Richard,
>
> I built a new kernel and tested this with old and new user space. It is
> working as advertised. The only thing I'm wondering about is why we have 3F
> as the default value when no additional info was sent? Would it be
On Tue, Jan 10, 2023 at 4:10 AM Jiri Olsa wrote:
> On Fri, Jan 06, 2023 at 10:43:59AM -0500, Paul Moore wrote:
> > When changing the ebpf program put() routines to support being called
> > from within IRQ context the program ID was reset to zero prior to
> > calling the
On Mon, Jan 9, 2023 at 10:59 AM Steve Grubb wrote:
> On Friday, January 6, 2023 3:33:18 PM EST Paul Moore wrote:
> > > This mailing list is *focused* on upstream work and support, and while
> > > it does not preclude talking about distro specific bugs, I believe
> >
On Mon, Jan 9, 2023 at 12:58 PM wrote:
> On 01/09, Paul Moore wrote:
> > On Fri, Jan 6, 2023 at 2:45 PM Stanislav Fomichev wrote:
> > >
> > > On Fri, Jan 6, 2023 at 7:44 AM Paul Moore wrote:
> > > >
> > > > It was determined that th
On Fri, Jan 6, 2023 at 2:45 PM Stanislav Fomichev wrote:
>
> On Fri, Jan 6, 2023 at 7:44 AM Paul Moore wrote:
> >
> > It was determined that the do_idr_lock parameter to
> > bpf_prog_free_id() was not necessary as it should always be true.
> >
> > Suggeste
On Fri, Jan 6, 2023 at 2:45 PM Stanislav Fomichev wrote:
> On Fri, Jan 6, 2023 at 7:44 AM Paul Moore wrote:
> >
> > When changing the ebpf program put() routines to support being called
> > from within IRQ context the program ID was reset to zero prior to
> > calli
On Mon, Jan 9, 2023 at 2:33 AM Burn Alting wrote:
>
> All,
>
> Would it be correct to say that when one sees an adjtimex system call audit
> event, a change has occurred ONLY if either a AUDIT_TIME_ADJNTPVAL (algorithm
> change) or AUDIT_TIME_INJOFFSET (time change) record is present in the
On Mon, Jan 9, 2023 at 3:30 AM Ariel Silver wrote:
>
> Hey guys and thank you for the quick reply, Much appreciated!
>
> As Richard and Steve mentioned the commit:
> https://github.com/linux-audit/audit-kernel/commit/1b2263a807ca651f94517b1b22dc5f13e494984d
> Fixed this issue.
A quick note for
On Thu, Jan 5, 2023 at 2:32 PM Paul Moore wrote:
> On Thu, Jan 5, 2023 at 11:32 AM Steve Grubb wrote:
> > On Thursday, January 5, 2023 10:41:49 AM EST Paul Moore wrote:
> > > On Thu, Jan 5, 2023 at 8:38 AM Ariel Silver
> > wrote:
> > > > I found the follo
erations with
the associated audit state (other audit records).
Cc: sta...@vger.kernel.org
Fixes: d809e134be7a ("bpf: Prepare bpf_prog_put() to be called from irq
context.")
Reported-by: Burn Alting
Reported-by: Jiri Olsa
Suggested-by: Stanislav Fomichev
Suggested-by: Alexei Starovoitov
S
It was determined that the do_idr_lock parameter to
bpf_prog_free_id() was not necessary as it should always be true.
Suggested-by: Stanislav Fomichev
Signed-off-by: Paul Moore
---
* v3
- initial draft
---
include/linux/bpf.h | 2 +-
kernel/bpf/syscall.c | 20 ++--
2 files
On Thu, Jan 5, 2023 at 11:32 AM Steve Grubb wrote:
> On Thursday, January 5, 2023 10:41:49 AM EST Paul Moore wrote:
> > On Thu, Jan 5, 2023 at 8:38 AM Ariel Silver
> wrote:
> > > I found the following bug:
> > >
> > > OS version = Red Hat Enterprise Linux r
1 - 100 of 2156 matches
Mail list logo
