Hello,
Trying to get one last email in just in case...
On Tuesday, October 31, 2023 9:17:17 PM EDT Paul Moore wrote:
> On Tue, Oct 31, 2023 at 5:24 PM Steve Grubb wrote:
> > I think the linux-audit mail list will be shutdown at midnight tonight
> > ...
>
> Whoa, that se
Hello,
I think the linux-audit mail list will be shutdown at midnight tonight. Watch
https://people.redhat.com/sgrubb/audit/
for updates. If we can continue somewhere, I'll link to it from that page.
There are mail archives such as
https://marc.info/?l=linux-audit&r=1&w=2
if you need histori
Hello,
Back in August I wrote an email detailing changes for an audit 4.0 release:
https://listman.redhat.com/archives/linux-audit/2023-August/020036.html
At this point, all changes have been made. I would like to ask anyone at a
distribution to please pull the master branch and give it a try. I
On Monday, October 23, 2023 9:06:16 AM EDT Rinat Gadelshin wrote:
> Hello there!
>
> First of all, I have to apologize for two identical emails as the
> beginning of the stream.
> The first one was sent (by occasional) from my work email.
> I've received notification, from the mail bot, that I sho
On Thursday, September 28, 2023 11:53:26 AM EDT Steve Grubb wrote:
> On Thursday, September 21, 2023 4:02:49 PM EDT Amjad Gabbar wrote:
> > > The best solution would be a kernel modification so that there are no
> > > mismatched lists.
> >
> > I agree as w
On Thursday, September 21, 2023 4:02:49 PM EDT Amjad Gabbar wrote:
> > The best solution would be a kernel modification so that there are no
> > mismatched lists.
>
> I agree as wellThis would be the cleanest solution. This would also
> solve the userspace problem of maintaining different lists
On Wednesday, September 20, 2023 2:45:26 PM EDT Steve Grubb wrote:
> On Tuesday, September 19, 2023 8:26:04 PM EDT Amjad Gabbar wrote:
> > > The perm fields select the right system calls
> > > that should be reported on.
> >
> > That is accurate from a functiona
On Tuesday, September 19, 2023 8:26:04 PM EDT Amjad Gabbar wrote:
> > The perm fields select the right system calls
> > that should be reported on.
>
> That is accurate from a functional perspective. There is no change in the
> events logged. But there is a difference in performance. This is most
On Friday, September 15, 2023 12:15:12 PM EDT Wieprecht, Karen M. wrote:
> We're working with Docker and podman, and I'm working on parsing the audit
> data we get to flag prohibited and missing command options based on STIG
> guidelines. I normally extract the proctitle from the raw auditd data
Hello,
On Tuesday, September 12, 2023 5:20:54 PM EDT Amjad Gabbar wrote:
> Based on this and some experiments I have been performing, I would suggest
> changing how a lot of the FileSystem rules are written and illustrated.
> Ex -
> https://github.com/linux-audit/audit-userspace/blob/master/rules/
Hello,
Thanks for reporting the issue.
On Friday, September 15, 2023 1:33:42 AM EDT Seyeong Kim wrote:
> Recently I've seen some people who faced below error msg while booting
> or while the machine is working.
>
> Error receiving audit netlink packet (No buffer space available)
> Error setting
Hello Paul,
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 both from a kernel load perspective (it
> > > should be able to handle the load, if not t
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 6:58 AM Tetsuo Handa
> > > wrote:
> > >> When an unexpected system event occurs, the administrator may wan
Hello,
I am considering making some drastic changes in a future 4.0 release. This is
partly motivated by a change in my daytime job. I am no longer working in Red
Hat security. Therefore working on audit is officially a hobby. I have spent
the last weeks closing out pull requests and Issues so
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
> > identify which application triggered the event. For example, unexpected
> > process termination is stil
On Monday, August 7, 2023 10:24:51 AM EDT Tetsuo Handa wrote:
> On 2023/08/07 7:01, Steve Grubb wrote:
> > This is where the problem begins. We like to have normalized audit
> > records. Meaning that a type of event defines the fields it contains. In
> > this case subject wou
Hello,
Paul can probably give you more feedback on ths from a technical PoV. BUt the
overall approach I can give some feedback.
On Sunday, August 6, 2023 9:04:55 AM EDT Tetsuo Handa wrote:
> When an unexpected system event occurs, the administrator may want to
> identify which application trigge
Hello,
I've just released a new version of the audit daemon. It can be
downloaded from http://people.redhat.com/sgrubb/audit. It will also be
in rawhide soon. The ChangeLog is:
- When processing a run level change, make auditd exit
- In auditd, fix return code when rules added in immutable mode
-
On Monday, July 24, 2023 5:06:02 PM EDT Samuel Bahr wrote:
> `auditctl -D` does not make it go away (outputs `No rules`). auditd isn't
> running at all and this behavior is happening purely from the kernel. These
> systems were never set to enabled 2 (locked).
>
> I went ahead and filed a Github i
On Thursday, June 29, 2023 6:34:03 PM EDT Samuel Bahr wrote:
> Hi linux-audit,
>
> I'm running a fleet of Linux hosts with Red Canary Linux EDR (Endpoint
> Detection and Response) which uses eBPF for gathering telemetry in service
> ` cfsvcd.service`. In an older configuration, it gathered data fr
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 kernel if that's
necessary. I think there's a fundamental mis
On Monday, June 5, 2023 6:17:28 PM EDT Vincent Abraham wrote:
> Greetings,
> Could anyone point me to a source for comprehensive documentation for the
> Linux audit framework? I want to know how the framework interacts with the
> kernel to retrieve log information.
If you look at the README page o
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 Ubuntu 22.04 x86_64 on virtual box by
> `root`):
>
> step #1:
Hello Warron,
On Tuesday, May 23, 2023 7:12:07 PM EDT warron.french wrote:
> Hi, I am running auditd-3.0.7-4 on an Alma Linux v8.8.
>
> I know that for all of RHEL 6 and RHEL 7 variants that I worked with, to
> include CentOS (not Stream) that after I rebooted a server or restarted the
> auditd s
when packages
> get deleted.
It does. The "op" field supports: remove, install, update.
-Steve
> On 5/16/23 21:12, Steve Grubb wrote:
> > Hello,
> >
> > On Sunday, May 14, 2023 8:24:47 PM EDT Claire Stafford wrote:
> >> This brings up the question of wher
Hello,
On Sunday, May 14, 2023 8:24:47 PM EDT Claire Stafford wrote:
> This brings up the question of where I can find the audit events which
> are generated by rpm?
ausearch --start today -m SOFTWARE_UPDATE
> Also dnf/yum if they directly generate events?
No, they are linked against librpm. It
s audit socket, all need to do is have the audit
daemon enabled. Then everything should work out. And you should find that
audit events written by auditd have slightly better information.
-Steve
> On Wed, May 10, 2023 at 9:51 AM Steve Grubb wrote:
> > On Wednesday, May 10, 2023
On Wednesday, May 10, 2023 9:43:04 AM EDT kathy lyons wrote:
> Good morning. I am trying to get the audit logs to be written only to
> audit.log. Currently they are written to audit.log as well as syslog.
> Here is my rsyslog.conf file - what am I doing wrong?
>
> module(load="imfile")
>
On Wednesday, May 10, 2023 9:30:19 AM EDT Tetsuo Handa wrote:
> On 2023/05/10 21:12, Rinat Gadelshin wrote:
> >> Please try to find who is calling audit_send_reply_thread for many
> >> times.
> >
> > I've rebuilt the kernel with 'dump stack()'.
>
> Oops, I thought dump_stack() shows pid and comm
On Friday, April 28, 2023 3:54:32 AM EDT 江杨 wrote:
> May I ask if Auditd supports Docker? Thank you
> https://listman.redhat.com/archives/linux-audit/2018-July/msg00078.html
There is no active work that I know of to put auditd in a container. It's
libraries are used by many applications. So, I do
Hello,
I've just released a new version of the audit daemon. It can be
downloaded from http://people.redhat.com/sgrubb/audit. It will also be
in rawhide soon. The ChangeLog is:
- Add user friendly keywords for signals to auditctl
- In ausearch, parse up URINGOP and DM_CTRL records
- Harden aupars
Hello,
On Thursday, April 13, 2023 12:23:31 PM EDT Carlos De Avillez wrote:
> Just checking is there is interest in the below.
Applied. Thanks!
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
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 time you've taken to read my emails and
> respond to them.
Ther
Hello,
On Wednesday, March 8, 2023 8:46:57 AM EST Richard Du wrote:
> I'm trying to define an audit rule with auditctl for clone() syscall, and I
> would expect that the a0 of clone() syscall (i.e. the clone_flags
> argument) without the CLONE_THREAD flag bit being set.
>
> int clone(int (*fn)(vo
On Wednesday, March 8, 2023 6:53:39 AM EST 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 contrib
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.
Thanks for the bug report. Let me know if you see anything else.
Upstream commit 7d35e14 should fix pa
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 audit-testsuite failures with the
> > latest upstream kernels and I tracked it down to a change in how the
> > IORING_
might benefit from adding a list_empty check.
A long time ago, I think we kept a variable that denoted if there were any
rules and short-circuited if none.
-Steve
> On Tue, Feb 14, 2023 at 8:29 AM Steve Grubb wrote:
> > Hello,
> >
> > On Monday, February 13, 2023 4:2
Hello,
On Monday, February 13, 2023 4:24:02 PM EST Amjad Gabbar wrote:
> I wanted some help in better understanding the workflow of file system
> auditing(watch rules) vs Syscall Auditing(syscall rules). I know in general
> file system auditing does not have the same performance impact as syscall
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 PM Richard Guy Briggs
wrote:
> > > > fadvise and madvise both provide hints for caching or access
Hello,
I've just released a new version of the audit daemon. It can be
downloaded from http://people.redhat.com/sgrubb/audit. It will also be
in rawhide soon. The ChangeLog is:
- Disable ProtectControlGroups in auditd.service by default
- Fix rule checking for exclude filter
- Make audit_rule_sys
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 Kara wrote:
> > > > On Fri 03-02-23 16:35:13, Richard Guy Briggs wrote:
> > > > > The Fanotify
tion in the
> AUDIT_FANOTIFY record. The following are examples of the new record
> format:
> type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1
> fan_info=3137 subj_trust=3 obj_trust=5 type=FANOTIFY
> msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=0 subj_tr
Hello,
On Wednesday, February 1, 2023 1:00:37 AM EST 布施 博明 wrote:
> Thank you for the comment.
> I also find following commit.
> -
> https://github.com/linux-audit/audit-userspace/commit/e63a8b16281701510164
> 70075396e3697dd57a9b
>
> BTW, I found another license question.
>
> The libauparse.s
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 notified
> of potentially malicious actions on their systens with respec
Hello,
On Monday, January 30, 2023 7:55:20 PM EST hiroaki.f...@ymail.ne.jp wrote:
> Dear All members,
>
> We can find following lines in audit/README file
>
> LICENSE
> ===
> The audit daemon is released as GPL'd code. The audit daemon's libraries
> libaudit.* and libauparse.* are released u
Hello,
On Monday, January 30, 2023 12:21:53 AM EST Anurag Aggarwal wrote:
> As per my understanding, currently auditd picks up rule files as per
> alphabetical order.
Auditd picks up the rules in /etc/audit/audit.rules That in turn is compiled
by augenrules which uses the order as given from "l
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.
> >
> > Suggested-by: Steve Grubb
> > Fixes: a56834e0fafe ("io_uring: ad
On Friday, January 27, 2023 5:57:30 PM EST Paul Moore wrote:
> 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,
> >
t; >>> 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 Stev
On Friday, January 27, 2023 3:00:37 PM EST Paul Moore wrote:
> 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,
> > > >
e records:
> type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1
> fan_info=3137 subj_trust=3 obj_trust=5 type=FANOTIFY
> msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F subj_trust=2
> obj_trust=2
>
> Suggested-by: Steve Grubb
> Link: https://lore.kernel.org/
On Monday, January 16, 2023 11:15:46 AM EST Avtansh Gupta wrote:
> Hello All,
>
> Please could you help me understand the difference between the following
> flags which are being used?
>
> AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH
This ^^^ means the kernel supports -F exe= in the rules.
https://list
Hello Richard,
On Monday, January 9, 2023 10:08:04 PM EST Richard Guy Briggs wrote:
> When I use an application that expected the old API, meaning it simply
> does:
> >
> > response.fd = metadata->fd;
> > response.response = reply;
> > close(metadata->fd);
> > write(fd, &response, sizeof(struct f
Hello,
On Tuesday, January 10, 2023 7:08:12 AM EST Anurag Aggarwal wrote:
> I need a method to identify whether the audid version a kernel is running
> supports path based exclusions.
It's not dependant on auditd. The kernel itself decides if a rule is valid.
> One option would be to use audit_
p=1 fan_type=0 fan_info=3F subj_trust=2
> obj_trust=2
>
> Suggested-by: Steve Grubb
> Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2
> Signed-off-by: Richard Guy Briggs
> ---
> fs/notify/fanotify/fanotify.c | 3 ++-
> include/linux/audit.h | 9 +
> ker
Hello,
On Monday, January 9, 2023 2:33:39 AM EST Burn Alting wrote:
> 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 t
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
> > there are better avenues for those discussions (e.g. see the RHBZ link
> > I provided in
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 release 8.6 (Ootpa)
> > Kernel version = 4.18.0-425.3.1.el8.x86_64
> > auditctl version = 3.0.7
>
> Th
Hello Burn,
On Tuesday, December 20, 2022 5:36:28 PM EST Burn Alting wrote:
> I note that the unsolicited AUDIT_BPF audit event only provides a program
> id and operation (load or unload). For example, type=BPF
> msg=audit(21/12/22 09:03:35.765:439) : prog-id=75 op=LOAD or type=BPF
> msg=au
Hello,
Thanks for the detailed notes on this investigation. It really is a lot of
good information backing this up. However, there will come a day when someone
sees this "major = ctx->major" and they will send a patch to "fix" this
unnecessary assignment. If you are sending a V2 of this set, I
Hello,
On Tuesday, September 13, 2022 12:53:32 PM EDT Manojkiran Eda wrote:
> I was working on leveraging the libaudit shared library to generate audit
> events from a user space daemon. I have been using the audit_open as well
> as audit_log_acct_message() API’s to send message to the kernel audi
On Friday, September 9, 2022 10:38:46 AM EDT Richard Guy Briggs wrote:
> > Richard, add subj_trust and obj_trust. These can be 0|1|2 for no, yes,
> > unknown.
>
> type? bitfield? My gut would say that "0" should be "unset"/"unknown",
> but that is counterintuitive to the values represented.
>
>
On Friday, September 9, 2022 7:09:44 AM EDT Jan Kara wrote:
> Hello Steve!
>
> On Fri 09-09-22 00:03:53, Steve Grubb wrote:
> > On Thursday, September 8, 2022 10:41:44 PM EDT Richard Guy Briggs wrote:
> > > > I'm trying to abide by what was suggested by t
On Thursday, September 8, 2022 10:41:44 PM EDT Richard Guy Briggs wrote:
> > I'm trying to abide by what was suggested by the fs-devel folks. I can
> > live with it. But if you want to make something non-generic for all
> > users of fanotify, call the new field "trusted". This would decern when
> >
On Thursday, September 8, 2022 5:22:15 PM EDT Paul Moore wrote:
> On Thu, Sep 8, 2022 at 5:14 PM Steve Grubb wrote:
> > On Wednesday, September 7, 2022 4:23:49 PM EDT Paul Moore wrote:
> > > On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb wrote:
> > > > On Wednesday, Se
On Wednesday, September 7, 2022 4:23:49 PM EDT Paul Moore wrote:
> On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb wrote:
> > On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs wrote:
> > > > > Ultimately I guess I'll leave it upto audit subsyst
On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs wrote:
> > > Ultimately I guess I'll leave it upto audit subsystem what it wants to
> > > have in its struct fanotify_response_info_audit_rule because for
> > > fanotify subsystem, it is just an opaque blob it is passing.
> >
> > In
On Wednesday, August 31, 2022 6:19:40 PM EDT Richard Guy Briggs wrote:
> On 2022-08-31 17:25, Steve Grubb wrote:
> > On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > >
On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > index 433418d73584..f000fec52360 100644
> > > --- a/kernel/auditsc.c
> > > +++ b/kernel/auditsc.c
> > > @@ -64,6 +64,7 @@
> > > #include
> > > #include
> > > #includ
Hello,
I've just released a new version of the audit daemon. It can be
downloaded from http://people.redhat.com/sgrubb/audit. It will also be
in rawhide soon. The ChangeLog is:
- In auditd, release the async flush lock on stop
- Don't allow auditd to log directly into /var/log when log_group is n
Hello Richard,
Although I have it working, I have some comments below that might improve
things.
On Tuesday, August 9, 2022 1:22:55 PM EDT Richard Guy Briggs wrote:
> Currently the only type of fanotify info that is defined is an audit
> rule number, but convert it to hex encoding to future-proof
Hello Richard,
On Wednesday, August 10, 2022 10:23:49 PM EDT Richard Guy Briggs wrote:
> > I compiled a new kernel and run old user space on this. The above event
> > is
> > exactly what I see in my audit logs. Why the fan_info=3F? I really would
> > have expected 0. What if the actual rule number
Hell Richard,
On Tuesday, August 9, 2022 1:22:55 PM EDT Richard Guy Briggs wrote:
> Currently the only type of fanotify info that is defined is an audit
> rule number, but convert it to hex encoding to future-proof the field.
>
> Sample record:
> type=FANOTIFY msg=audit(1659730979.839:284): res
On Tuesday, August 2, 2022 8:56:21 PM EDT Paul Moore wrote:
> I can tell you that I've never been really excited about the /proc
> changes, and believe it or not I've been thinking about those a fair
> amount since James asked me to start maintaining the LSM.
Why do we not have auid and session
Hello,
On Monday, July 11, 2022 10:14:40 PM EDT Ken Hornstein wrote:
> >It is advisable to use the heartbeat option. This way each end can detect
> >the other "disappeared" for some reason.
>
> Well, the default configuration is that heartbeats are turned off, so
> the general impression I would
Hello,
On Thursday, July 7, 2022 12:05:28 AM EDT Ken Hornstein wrote:
> So we've been struggling with getting audisp-remote working in a
> reliable manner. In summary, it works but the networking seems fragile.
> We are using Kerberos authentication with audisp-remote, but that
> doesn't seem to
Hello Paul,
On Tuesday, June 7, 2022 9:42:06 AM EDT Paul Moore wrote:
> On Mon, Jun 6, 2022 at 7:10 PM Lenny Bruzenak wrote:
> > I've been told that it is not a potential security problem, and not
> > subject to change in the (current) kernel.
>
> I'm that little birdy that Lenny was talking to o
Hello,
On Thursday, May 12, 2022 4:01:34 AM EDT Sam Pinkus wrote:
> I'm using auditd=1:2.8.4-3 on Debian. I got this event in my audit.log:
>
>
> ...
> type=SYSCALL msg=audit(16523210---): arch=c03e syscall=87 success=yes
> exit=0 a0=7f867d66a3ed a1=7f867d66a3ed a2=0 a3=792f18 items=2 ppid=2
Hello Jan,
On Thursday, May 5, 2022 10:44:56 AM EDT Jan Kara wrote:
> On Tue 03-05-22 21:33:35, Richard Guy Briggs wrote:
> > On 2022-05-02 20:16, Paul Moore wrote:
> > > On Thu, Apr 28, 2022 at 8:45 PM Richard Guy Briggs
wrote:
> > > > This patch adds 2 structure members to the response returne
On Thursday, April 28, 2022 8:55:33 PM EDT Richard Guy Briggs wrote:
> On 2022-04-28 20:44, 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 inher
Hello,
On Tuesday, May 3, 2022 5:02:11 AM EDT Sven Schnelle wrote:
> socketcall auditing misses the call argument:
>
> type=SOCKETCALL msg=audit: nargs=3 a0=10 a1=3 a2=c
>
> which renders socketcall auditing (almost) useless. Add the call
> argument so it is possible to decode the actual syscall
On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote:
> On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote:
> > On Wed, Mar 30, 2022 at 10:29 PM CGEL wrote:
> > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote:
> > > > If audit is not generating SYSCALL records, even for inval
Hello,
I've just released a new version of the audit daemon. It can be
downloaded from http://people.redhat.com/sgrubb/audit. It will also be
in rawhide soon. The ChangeLog is:
- Add gcc function attributes for access and allocation
- Add some more man pages (MIZUTA Takeshi)
- In auditd, change t
Hello,
On Wednesday, March 2, 2022 4:45:07 PM EST Amjad Gabbar wrote:
> Had a couple of concerns that I wanted to discuss:
>
> 1.
>
> I was getting a few "auditd queue full" messages in syslog. I had
> previously faced similar issues after which I had increased the q_depth and
> modified my rule
Hello,
On Wednesday, March 2, 2022 4:45:07 PM EST Amjad Gabbar wrote:
> Had a couple of concerns that I wanted to discuss:
Thanks for the report. Before I answer the full email, which version of
auditd are you using? I want to make sure I'm looking at the right code when
answering.
Thanks,
-St
Hello,
On Wednesday, March 2, 2022 10:51:57 AM EST MAUPERTUIS, PHILIPPE wrote:
> During an audit, we had a question about stopping auditd.
> What will be the best way either to get an alert when auditd is stopped ?
Since by now everything probably uses systemd, I think you can add an
OnFailure=
On Monday, February 28, 2022 12:29:54 PM EST Mark Gardner wrote:
> Notice no information on what file was copied / removed?
>
> Even the earlier log entries don't show what file was copied / removed.
This might be related to record formats changing.
> If I downgrade to audit 3.0-0.17, everyt
Hello,
On Monday, February 21, 2022 4:50:22 PM EST Steve Grubb wrote:
> Recently, distributions moved to building against gcc-12 for their latest
> OS composes. It's been found in at least 2 distributions that the user
> space package is failing to build. It's natural to th
Hello,
On Monday, February 21, 2022 4:50:22 PM EST Steve Grubb wrote:
> A short term fix might be for distros to copy the kernel header into the
> lib directory and patch it to restore buf[0];, then change libaudit.c to
> include "audit.h" instead of . There may be other
>
Hello,
On Wednesday, February 23, 2022 1:32:31 PM EST Roger Moore wrote:
> Can you let me know how to remove all audit code, including audit-libs
> and python3-audit, and stop them from being updated by DNF update.
>
> DNF keeps reinstalling the python3 code (audit-libs python3-audit).
>
>
Hello,
Recently, distributions moved to building against gcc-12 for their latest OS
composes. It's been found in at least 2 distributions that the user space
package is failing to build. It's natural to think this is related to gcc-12
since it's the obvious change.
However, the problem is a co
nter-process kernel buffer
with the plugin. Only 2 of those have config options.
>But different distros seem to have different default
>values for q_depth ranging from 80 to 1200. How is it possible that
> these numbers vary but the size of the buffer remains 128k.
It's a diffe
Hello,
I've just released a new version of the audit daemon. It can be
downloaded from http://people.redhat.com/sgrubb/audit. It will also be
in rawhide soon. The ChangeLog is:
- Add support for the OPENAT2 record type (Richard Guy Briggs)
- In auditd, close the logging file descriptor when loggi
On Tuesday, January 11, 2022 1:37:18 AM EST Rohit wrote:
> Hello Steve,
>
> Thank you, that's very helpful.
>
> > The compound events always have a syscall event, but as to the auxiliary
>
> records,
> it really depends on the path the syscall takes through the kernel. Various
> places are hooke
Hello,
On Monday, January 10, 2022 3:32:55 PM EST Rohit wrote:
> Question 1
> I'm not even sure if this is feasible but does there exist an audit rule
> type <--> record type mapping?
Nope.
> For example, a file watch rule for writes and attribute changes (-p wa)
> would generate record types o
Hello,
On Tuesday, December 21, 2021 12:55:47 AM EST Amjad Gabbar wrote:
> Based on our discussion above, I performed some analysis as to why we were
> seeing so many events. The reason seems to be due to the default rules
> being triggered every time a cron job runs. We have numerous cron jobs
>
ch is why the reasoning
> of increasing q_depth to backlog_limit.
The q_depth being 90 is your likely problem. Realistically, that only allows
20 - 30 events to be enqueued.
-Steve
> On Wed, Dec 8, 2021 at 4:38 PM Steve Grubb wrote:
> > On Wednesday, December 8, 2021 4:54:18 PM EST Amja
af_unix client to see if it's the problem.
Cheers,
-Steve
> On Wed, Dec 1, 2021 at 10:00 AM Steve Grubb wrote:
> > Hello,
> >
> > On Tuesday, November 30, 2021 6:04:28 PM EST Amjad Gabbar wrote:
> > > I am currently seeing a lot of auditd dispatch error
Hello,
On Tuesday, November 30, 2021 6:04:28 PM EST Amjad Gabbar wrote:
> I am currently seeing a lot of auditd dispatch error issues.
What version of auditd and what plugins do you have?
> It is related to a particular keyed rule that from the looks of it is
> generating close to a million even
1 - 100 of 1844 matches
Mail list logo
