Re: Linux Audit Mail List

[Steve Grubb]

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 seems rather abrupt, is the mail server being shut down?
> Or something else?

This mail list is run by an ancient version of mailman. It has not been 
updated in a decade (no upstream releases). It was deemed a security risk. I 
have been working behind the scenes to try to keep it alive, but I now work 
in the AI group - not security. So, I have no way to keep this alive except 
by good luck...which I think run its course. They gave me several options 
which all were bad. I was hoping for a different outcome. For example, one 
option was google groups which would involve me manually adding any new 
subscriber. That's no good as I have no idea who wants to subscribe. Sorry 
for the inconvenience folks...

> > There are mail archives such as
> > 
> > https://marc.info/?l=linux-audit=1=2
> 
> The linux-audit@redhat list is also archived on lore.kernel.org, a
> link to the archive is below:
> 
> * https://lore.kernel.org/linux-audit

Yes, there are several others subscribed, too.
 
> If those interested in upstream userspace development wanted to
> migrate to the audit@vger list I see no problem with that, link below:
> 
> * http://vger.kernel.org/vger-lists.html#audit

Maybe. I guess we'll need to chat by private email. But if we find a new home, 
I'll post it to my people page.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Linux Audit Mail List

[Steve Grubb]

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=1=2

if you need historical information.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Audit status update

[Steve Grubb]

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. It is 
suggested to package audit-rules, auditctl, and augenrule + the new systemd 
service separately. 

In order for the new audit-rules.service to be enabled out of the box, you 
will also need to coordinate a systemd preset. On Fedora, that would be:

 /usr/lib/systemd/system-preset/90-default.preset

which now includes:

enable auditd.service
enable audit-rules.service

I am aiming this change for Fedora 40 since that is the current one in 
development. Getting this enabled by default on Fedora requires a ticket and 
approval. I could imagine there are are similar procedures at other distros. 
Meaning when audit-4.0 is released, it may take some time before you see it 
in a distro.

The python updates required splitting libaudit.h into 2 files. The new file 
audit-logging.h is included by libaudit.h, so no user visible changes should 
be noticed.

Also, by restricting the API in the python bindings, I only know of one 
application that was relying on the extended API, setroubleshoot. Be on the 
lookout for other applications that might be broken.

The current master branch will be tagged as 4.0 alpha which is for testing. 
Please check this soon...because...the audit mail list might be going away 
soon. I am trying to preserve it but I think we are running out of time and 
options. If we lose the mail list, report items on github. And if I can 
arrange a new mail list, I will point to it from my people.redhat.com page.

Lastly, there is a new github branch, audit-3.1-maint. I have cherry-picked 
patches that I think are important for a 3.1.3 release if that ever happens. 
But know that I am not testing it and a release may never happen. Treat it 
more as a suggestion of patches you might want to include during any 
maintenance release you might do.

Please let me know any issues found in testing. Audit-4.0 will be released in 
the next month or so depending on feedback and FESCO approval.

Best Regards,
-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Couldn't get audit messages for 'listen' on kernel 4.19.0-6-686-pae

[Steve Grubb]

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 should subscribe
> to the mail list (for the work email).
> After that I've resent the second one.
> 
> Let's return to the problem.
> 
> I've done a following experiment:
> 
> `auditctl -D`
> `auditctl -a always,exit -S all`
> `strace netcat -v -l -p 4242 | tee strace.log` # the pid of the netcat
> was 536
> Ctrl+c
> `ausearch -p 536 > auditd.pid.536.log`
> `grep "syscall=.*traditional" auditd.pid.536.log | awk '{print $4}' |
> sort | uniq -c'
> 
> The last command prints the following result:
> 
>   11 syscall=102
>1 syscall=11
>6 syscall=125
>6 syscall=140
>6 syscall=174
>1 syscall=175
>   14 syscall=192
>   33 syscall=195
>9 syscall=197
>2 syscall=20
>1 syscall=243
>1 syscall=27
>   41 syscall=295
>   14 syscall=3
>5 syscall=33
>2 syscall=4
>5 syscall=45
>   11 syscall=6
>3 syscall=91
> 
> So the following syscalls are reported (there are no `socket`, `bind`,
> `connect`, `listen`):
> 
>  3 (read)
>  4 (write)
>  6 (close)
>  11 (execve)
>  20 (getpid)
>  27 (alarm)
>  33 (access)
>  45 (brk)
>  91 (munmap)
>102 (socketcall)

On old 386 kernels, they use socketcall as the networking API. Glibc under 
the hood sets arg0 to a number which represents the actual functionality to 
call and calls socketcall. You could say it multiplexes the network API. 
Somewhere along the way, they decided to modernize and make actual calls for 
each network function. So, if you have an audit library that is much newer 
than the kernel, it will assume you are using the updated API rather than the 
socketcall based API. In this case, you have an old glibc which still uses 
socketcall.

So, if you wanted to audit socket, bind, connect, and listen you would use:

 -a always,exit -F arch=b32 -S socketcall -F arg0=1 -F key=socket
 -a always,exit -F arch=b32 -S socketcall -F arg0=2 -F key=bind
 -a always,exit -F arch=b32 -S socketcall -F arg0=3 -F key=connect
 -a always,exit -F arch=b32 -S socketcall -F arg0=4 -F key=listen

A listing of the numbers to use can be found at:
/usr/include/linux/net.h

Hope this helps...

-Steve

>125 (mprotect)
>140 (_llseek)
>174 (rt_sigaction)
>175 (rt_sigprocmask)
>192 (mmap2)
>195 (stat64)
>197 (fstat64)
>243 (set_thread_area)
>295 (openat)
> 
> But strace's log shows that `socket`, `bind`, `connect` and `listen`
> were called:
> 
>  execve("/usr/bin/netcat", ["netcat", "-v", "-l", "-p", "4242"],
> 0xbf9f8f00 /* 22 vars */) = 0
>  -- line skipped --
>  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
>  connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"},
> 110) = -1 ENOENT (No such file or directory)
>  close(3)= 0
>  -- line skipped --
>  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
>  connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"},
> 110) = -1 ENOENT (No such file or directory)
>  close(3)= 0
>  -- line skipped --
>  socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
>  setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>  setsockopt(3, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
>  bind(3, {sa_family=AF_INET, sin_port=htons(4242),
> sin_addr=inet_addr("0.0.0.0")}, 16) = 0
>  listen(3, 1)= 0
>  getsockname(3, {sa_family=AF_INET, sin_port=htons(4242),
> sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
>  -- line skipped --
> 
> Please, give me a clue! How could it be?
> 
> Best regards
> Rinat
> 
> On 22.10.2023 08:27, Rinat Gadelshin wrote:
> > Hello there!
> > 
> > I'm facing a strange problem.
> > I have not been able to get audit reports for any "network" syscall
> > on one of the computers from my test bench.
> > I mean 'connect', 'accept4', 'listen', 'bind', 'socket'.
> > The following example shows that auditd couldn't get them too
> > ('listen' at least).
> > But I've received a report about 'execve' called by the same process.
> > 
> > Could you tell me what can I do in order to receive audit messages for
> > the syscalls.
> > from this version of the kernel?
> > 
> > Any help will be will be appreciated.
> > 
> > 
> > root@deb101-x86-0009:~# netcat -v -l -p 4242 &
> > [2] 13481
> > root@deb101-x86-0009:~# listening on [any] 4242 ...
> > root@deb101-x86-0009:~# echo "Test" | nc -q 0 127.0.0.1 4242
> > connect to [127.0.0.1] from localhost [127.0.0.1] 36650
> > Test
> > root@deb101-x86-0009:~# skill -p 13481
> > [2]+  Donenetcat -v -l -p 4242
> > root@deb101-x86-0009:~# 

Re: Sycall Rules vs Watch Rules

[Steve Grubb]

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 wellThis would be the cleanest solution. This would also
> > solve the userspace problem of maintaining different lists which can get
> > out of hand fairly quickly.
> 
> After looking into this, a kernel patch would also not work well. It has to
> be arch specific
> 
> > > I guess we can warn on that to rewrite in syscall notation.
> > 
> > We certainly should. I think the user should know that there is a
> > performance cost associated with watches and we should explicitly mention
> > how it can be optimized in the manpages also. The reason being I am
> > pretty sure, numerous users/repos still do make use of the -w notation
> > and we do want to let them know the issue here. We also need to make
> > quite a few changes to the manpages also regarding this. Because,
> > initially even I was  very confused when reading the man pages and seeing
> > the actual implementation of and results were not quite in sync.
> 
> I have made the changes to the master and audit-3.1-maint branches. Please
> everyone concerned give them tests. The short of it is that if you use the
> '- w' notation for watches, it will remain the same and slower.

Actually, ths is the one that draws the warning to urge people to migrate.

> If you use
> the syscall notation without "-F arch", you will get a warning that it
> cannot be optimized without adding "-Farch".

Actually, you won't in order to preserve intentional behavior.

> If you add "-F arch", you
> will possibly need one for both arches which means doubling the rules. If
> you do not want to double the rules, you might place a syscall rule for
> any 32 system call (21-no32bit.rules). Or you can leave it as is and not
> care. The sample rules and all man pages have been updated.

I should have provided an example of what this means. If you have this kind
of rule:

-w /etc/shadow -p wa -k shadow

And when applied draws a warning:

# auditctl -w /etc/shadow -p wa -k shadow
Old style watch rules are slower

It should be rewritten as

-a always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -F key=shadow

Then it looks like this when loaded:

#auditctl -l
-a always,exit -F arch=b64 -S 
open,bind,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,chmod,fchmod,chown,fchown,lchown,mknod,acct,swapon,quotactl,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,openat,mkdirat,mknodat,fchownat,unlinkat,renameat,linkat,symlinkat,fchmodat,fallocate,renameat2,openat2
 -F path=/etc/shadow -F perm=wa -F key=shadow

And to delete  the rule, 
auditctl -d always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -F key=shadow

or the long way

auditctl -d always,exit -F arch=b64 -S 
open,bind,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,chmod,fchmod,chown,fchown,lchown,mknod,acct,swapon,quotactl,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,openat,mkdirat,mknodat,fchownat,unlinkat,renameat,linkat,symlinkat,fchmodat,fallocate,renameat2,openat2
 -F path=/etc/shadow -F perm=wa -F key=shadow

Hopefully this is clearer what the change is.
 
-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Sycall Rules vs Watch Rules

[Steve Grubb]

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 which can get
> out of hand fairly quickly.

After looking into this, a kernel patch would also not work well. It has to 
be arch specific
 
> > I guess we can warn on that to rewrite in syscall notation.
> 
> We certainly should. I think the user should know that there is a
> performance cost associated with watches and we should explicitly mention
> how it can be optimized in the manpages also. The reason being I am pretty
> sure, numerous users/repos still do make use of the -w notation and we do
> want to let them know the issue here. We also need to make quite a few
> changes to the manpages also regarding this. Because, initially even I was
> very confused when reading the man pages and seeing the actual
> implementation of and results were not quite in sync.

I have made the changes to the master and audit-3.1-maint branches. Please 
everyone concerned give them tests. The short of it is that if you use the '-
w' notation for watches, it will remain the same and slower. If you use the 
syscall notation without "-F arch", you will get a warning that it cannot be 
optimized without adding "-Farch". If you add "-F arch", you will possibly 
need one for both arches which means doubling the rules. If you do not want 
to double the rules, you might place a syscall rule for any 32 system call 
(21-no32bit.rules). Or you can leave it as is and not care. The sample rules 
and all man pages have been updated.

Please, let me know if this works out better.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Sycall Rules vs Watch Rules

[Steve Grubb]

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 functional perspective. There is no change in the
> > events logged. But there is a difference in performance. This is most
> > evident for syscalls not part of the perm fields.
> 
> 
> 
> > If we look at the performance numbers for the file rules as is, the
> > auditing percentage is about 14%.
> > 
> > Now if we were to just add the specific syscalls that the perm fields
> > filter on in the rules file, the auditing percentage would drop to around
> > 2%.
> 
> I think I am mis-remembering something, or there was a change way back in
> the beginning. The plan was that we could optimize access by letting the
> kernel pick the relevant syscalls based on the permissions. User space
> would just define the permissions and the kernel would make it so.
> 
> But there were several redesigns of the file auditing. I looked back as far
> as the 3.1 kernel and it always follows lookup the syscall, if it's
> relevant, then check the rest of the fields in the rule. This eventually
> checks the set of syscalls selected by the perms.
> 
> The way that it should have worked is when perms is given, throw away any
> syscalls and set the mask based on the perms selected. That would have been
> optimal and it was what Al Viro and I talked about long ago. However, it
> went through several redesigns.

I did some digging. This is the original patch:
https://listman.redhat.com/archives/linux-audit/2006-August/003593.html

Al does mention that syscalls taking a descriptor should not be included. I 
guess that can be cleaned up in the include/asm-generic/audit_*.h files.

I think that patch would have landed in the 2.6.18 kernel. I found a 2.6.21 
kernel and the path taken is different:

audit_syscall_exit
audit_get_context
audit_filter_inodes   <--- this is where it differs
audit_filter_rules
audit_match_perm

In the old kernel, it still called the syscall filter. But I think that was 
optimized later. But the whole point of making the perms field was so that 
user space could just tell the kernel what it needs and the kernel would 
select exactly the syscalls needed. There was no other reason to have it.

Now, what to do about it? A watch was biarch. There were 2 tables for 32 & 64 
bits and it would swing between them based on the syscall's arch. To fix this 
in user space would mean a watch would have to create 2 rules to cover 
biarch. And some systems conceivably may not have 32 bit enabled or vice 
versa. There would be no way for user space to know and work around a missing 
arch.

The  -w notation really can't be optimized. It doesn't specify an arch so it 
has to be "all". I guess we can warn on that to rewrite in syscall notation.

-Steve

> The problem now is that user space has no list of syscalls that match each
> permission. And then, there's no good way to sync based on mixing and
> matching kernels and user space. The kernel may have an updated syscall
> list user space doesn't know about and vice versa.
> 
> I think you are on to something important. But I am surprised my concept of
> how it works doesn't match the implementation. (Al Viro did the original
> implementation way back around 2006/7.) The best solution would be a
> kernel modification so that there are no mismatched lists. A suboptimal
> solution would be to maintain 2 lists and hope they don't change. Which by
> the way, I think the kernel lists are outdated again. (Syscalls keep
> getting added - quotactl_fd for example)
> 
> -Steve
> 
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://listman.redhat.com/mailman/listinfo/linux-audit




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Sycall Rules vs Watch Rules

[Steve Grubb]

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
> evident for syscalls not part of the perm fields.

 

> If we look at the performance numbers for the file rules as is, the
> auditing percentage is about 14%.
> 
> Now if we were to just add the specific syscalls that the perm fields
> filter on in the rules file, the auditing percentage would drop to around
> 2%.

I think I am mis-remembering something, or there was a change way back in the 
beginning. The plan was that we could optimize access by letting the kernel 
pick the relevant syscalls based on the permissions. User space would just 
define the permissions and the kernel would make it so.

But there were several redesigns of the file auditing. I looked back as far as 
the 3.1 kernel and it always follows lookup the syscall, if it's relevant, 
then check the rest of the fields in the rule. This eventually checks the set 
of syscalls selected by the perms.

The way that it should have worked is when perms is given, throw away any 
syscalls and set the mask based on the perms selected. That would have been 
optimal and it was what Al Viro and I talked about long ago. However, it went 
through several redesigns.

The problem now is that user space has no list of syscalls that match each 
permission. And then, there's no good way to sync based on mixing and 
matching kernels and user space. The kernel may have an updated syscall list 
user space doesn't know about and vice versa.

I think you are on to something important. But I am surprised my concept of 
how it works doesn't match the implementation. (Al Viro did the original 
implementation way back around 2006/7.) The best solution would be a kernel 
modification so that there are no mismatched lists. A suboptimal solution 
would be to maintain 2 lists and hope they don't change. Which by the way, I 
think the kernel lists are outdated again. (Syscalls keep getting added - 
quotactl_fd for example)

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: 128 Character limit on proctitle field?

[Steve Grubb]

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 ,
> but these commands are very long with sometimes 23 or more command line
> parameters ,  and I noticed that all of the auditd proctitle data for the
> lengthier commands is being cut off at 128 characters.

The proctitle event commit message explains why it was created:
https://listman.redhat.com/archives/linux-audit/2014-February/008778.html

The comm field is only 16 characters long. So, it tries to capture the first 
128 bytes so that at least android comm fields can be deduced since they are 
almost always larger than 16 bytes.

> I'm bringing this up  for two reasons:
> 
>  One,  not everyone working with this data may realize that there seems
> to be a character limit, and second, if this is by chance a bug as opposed
> to intentional,  then I'm hoping we can get a fix cooking for it?

The record that contains all of the command line is the execve record. It has 
all parameters even if it's 10,000. So, you may want to try auditing by exec 
of specific applications to get everything.

Also, as mentioned in the commit, proctitle is based off of comm. This can be 
controlled by user space to misdirect attention by spoof the program name.

> In the meantime,  I may be able to work around this by piecing together the
> full command from the "a#= "  fields, but it would be much easier if
> proctitle wasn't cut off after 128 chars.
> 
> Thanks, any info you can share would be much appreciated,

This was intentional. There was a long discussion of this in January and 
February of 2014 if you want more background.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Sycall Rules vs Watch Rules

[Steve Grubb]

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/30-pci-dss
> -v31.rules#L34-L35
> 
> The rule in the repository is
> -a always,exit -F path=/etc/sudoers -F perm=wa -F
> key=10.2.2-priv-config-changes
> 
> My suggestion is to instead change the rule based on the permissions
> defined. The above rule would change to the following based on the kernel
> being used.
> -a always,exit -S  +open,openat> -F path=/etc/sudoers -F perm=wa -F
> key=10.2.2-priv-config-changes

That should be exactly what the kernel does with the perm fields. The perm 
fields select the right system calls that should be reported on.
 
> This is higher performance because we are limiting the syscalls instead of
> making use of -S all which has more paths of evaluation for each and every
> syscall.
> 
> Same thing for watches. Watches are inherently -S all rules which are very
> performance intensive.
> https://github.com/linux-audit/audit-userspace/blob/1482cec74f2d9472f81dd4f
> 0533484bd0c26decd/lib/libaudit.c#L805

There should be no difference in performance between watches and syscall 
based file auditing.

> Ideally we should limit the syscalls based on the permissions being used.
> 
> I have implemented the same in my environment rules and have noticed a
> massive performance difference with no difference in the events being
> logged since we anyways filter eventually based on the permissions.
> 
> Let me know what you all think.

I'm looking into this more. I see a 1 line change that I am testing.

-Steve

> On Wed, Sep 6, 2023 at 2:58 PM Richard Guy Briggs  wrote:
> > On 2023-09-06 10:56, Amjad Gabbar wrote:
> > > Hi,
> > > 
> > > I have done some analysis and digging into how both the watch rules and
> > > syscall rules are translated.
> > > 
> > > From my understanding, in terms of logging, both the below rules are
> > > similar. There is no difference in either of the rules.
> > > 
> > > 1. -w /etc -p wa -k ETC_WATCH
> > 
> > They are similar in this case.
> > -w behaves differently depending on the existance of the watched entity
> > and the presence of a trailing "/".  This is why the form above is
> > deprecated.
> > 
> > > 2. -a always,exit -F arch=b64 -S  > > attr
> > > classes> -F dir=/etc  -F perm=wa -k ETC_WATCH
> > > 
> > > The write and attr classes consist of syscalls in
> > > “include/asm-generic/audit_*.h“.
> > > 
> > >  The perm flag is needed in the second case for including open/openat
> > > 
> > > syscalls which are not a part of the write and attr syscall list.
> > > 
> > > I'd like to verify if what I mentioned earlier is accurate, and I have
> > > an
> > > additional point but depends on whether this is accurate.
> > > 
> > > Ali
> > 
> > - RGB
> > 
> > --
> > Richard Guy Briggs 
> > Sr. S/W Engineer, Kernel Security, Base Operating Systems
> > Remote, Ottawa, Red Hat Canada
> > Upstream IRC: SunRaycer
> > Voice: +1.613.860 2354 SMS: +1.613.518.6570




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Increasing audit netlink buffer size

[Steve Grubb]

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 audit daemon pid (No buffer space available)
> Unable to set audit pid, exiting
> 
> increasing q_depth=75000 and -b 8192 didn't help for them.
> 
> There is no stable reproducer but I suspect this is because the
> default netlink buffer is not big enough.

The default netlink buffer is set by this sysctl:

# sysctl net.core.rmem_default
net.core.rmem_default = 212992

200k should be plenty to hold a 9k netlink packet at the most.

> Below were my test steps to
> see the above msg.
> 
> 1. launch instance
> 2. enable audit with kernel parameters
> 3. run for i in {1..10}; do auditctl --reset-lost; done
> 4. while running #3, keep restarting systemctl restart auditd

Hmm. restarting auditd via systemctl can be problematic. It has to wait for 
auditd to terminate or you can have 2 active at once. This is one of the 
reasons why we disallow the direct use of systemctl to 

> I wasn't able to let them test this test pkg but could you please give
> me any advice related to this if it makes sense or not?

This is the only report of this I've heard of. Which kernel? Has the sysctl 
been modified from the default? What are the audit parameters given at the 
boot prompt? Which version of the audit package?

I don't think the code in this area has changed for a long time. Also, 
recvfrom man page does not mention ENOBUFS. The netlink(7) man page seems to 
indicate something about acks possibly causing this. However, loading rules 
is done one at at time. I don't really understand how it gets backed up like 
this unless 2 auditd are stepping on each other somehow.

-Steve

> Thanks in advance. Regards
> 
> Index: audit-3.0.7/lib/netlink.c
> ===
> --- audit-3.0.7.orig/lib/netlink.c
> +++ audit-3.0.7/lib/netlink.c
> @@ -34,6 +34,9 @@
>  #ifndef NETLINK_AUDIT
>  #define NETLINK_AUDIT 9
>  #endif
> +#ifndef SO_RCVBUFFORCE
> +#define SO_RCVBUFFORCE 33
> +#endif
> 
>  static int adjust_reply(struct audit_reply *rep, int len);
>  static int check_ack(int fd);
> @@ -47,6 +50,7 @@ static int check_ack(int fd);
>  int audit_open(void)
>  {
> int saved_errno;
> +   int rcvbuf;
> int fd = socket(PF_NETLINK, SOCK_RAW, NETLINK_AUDIT);
> 
> if (fd < 0) {
> @@ -62,6 +66,19 @@ int audit_open(void)
> errno = saved_errno;
> return fd;
> }
> +
> +   rcvbuf = 10*1024*1024;  // size is temp value for now.
> +   if (setsockopt(fd, SOL_SOCKET, SO_RCVBUFFORCE,
> +  , sizeof(rcvbuf))) {
> +   saved_errno = errno;
> +   audit_msg(LOG_ERR,
> +   "Error setting netlink sock buffer size (%s)",
> +   strerror(errno));
> +   close(fd);
> +   errno = saved_errno;
> +   return -1;
> +   }
> +
> if (fcntl(fd, F_SETFD, FD_CLOEXEC) == -1) {
> saved_errno = errno;
> audit_msg(LOG_ERR,
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://listman.redhat.com/mailman/listinfo/linux-audit




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH] audit: add task history record

[Steve Grubb]

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 that is a separate problem
> > > to address) as well as the human perspective (if you want auditing,
> > > you need to be able to handle auditing).
> > 
> > No. You haven't shown us audit rules that can satisfy requirements shown
> > below.> 
> >   (1) Catch _all_ process creations (both via fork()/clone() system calls
> >   and kthread_create() from the kernel), and duplicate the history upon
> >   process creation.
> 
> Create an audit filter rule to record the syscalls you are interested
> in logging.
> 
> >   (2) Catch _all_ execve(), and update the history upon successful
> >   execve().
> 
> Create an audit filter rule to record the syscalls you are interested
> in logging.
> 
> >   (3) Catch _all_ process terminations (both exit()/exit_group()/kill()
> >   system  calls and internal reasons such as OOM killer), and erase the
> >   history upon process termination.
> 
> Create an audit filter rule to record the events you are interested in
> logging, if there is an event which isn't being recorded feel free to
> submit a patch to generate an audit record.

I'm not for or against this or a similar patch. The information Tetsuo is 
looking for cannot be recreated from logs. What if it were a daemon that's 
been running for a year? With the amount of data you are suggesting to log, 
it would have rotated away months ago. To log all of the system calls you 
mention would be abusive of the audit system, hurt performance, wear out SSD 
drives, and ultimately fail.

There may be other reasons you don't like the patch and that's fine. But 
saying it can be done from user space after the fact is not helpful.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH] audit: add task history record

[Steve Grubb]

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 want to
> > >> identify which application triggered the event. For example,
> > >> unexpected process termination is still a real concern enough to write
> > >> articles like https://access.redhat.com/solutions/165993 .
> > >> 
> > >> This patch adds a record which emits TOMOYO-like task history
> > >> information into the audit logs for better understanding of unexpected
> > >> system events.
> > >> 
> > >> type=UNKNOWN[1340] msg=audit(1691750738.271:108):
> > >> history="name=swapper/0;pid=1;start=20230811194329=>name=init;pid=1;s
> > >> tart=20230811194343=>name=systemd;pid=1;start=20230811194439=>name=ssh
> > >> d;pid=3660;start=20230811104504=>name=sshd;pid=3767;start=202308111045
> > >> 35"
> > >
> > > While I respect your persistence, we've talked about this quite a bit
> > > already in other threads.  What you are trying to do is already
> > > possible with audit
> > 
> > How?
> 
> If you configure audit to record exec() and friends you should have a
> proper history of the processes started on the system.

This is not a practical solution. Yes, technically this could be done. But it 
would be a huge burden on the system to keep up with this. And it would bury 
events you truly wanted to see effectively DoS'ing the audit system.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

[RFC] Future audit changes

[Steve Grubb]

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 that whoever wants to 
contribute to the audit project doesn't have a lot of history to deal with. 
There's almost 500 people subscribed to this list. The community needs to 
step up a little.

The proposed changes are:

1) Drop support for Python 2. Python 2 has lost upstream support over 3 years 
ago. I also can't see the viability of someone saying they need the latest 
audit changes for the new kernel yet they are stuck on python 2. It doesn't 
compute. This is also related to proposal 5 below.

2) Drop SysVinit support. I think everyone has changed to systemd at this 
point. This is to reduce potential maintenance.

3) This is probably the most controversial and would need careful testing: 
Split the audit service into 2 services: auditd and rules-load. These would 
be packaged in 2 different packages so that if all you want is rules-loading 
and are fine with events going to journald - have at it. If you want the 
tradition audit experience, then install the audit package which will depend 
on the rules package. The trick is making them automatically enabled at 
install. This will need testing and perhaps patches. Packagers will need to 
work with their distribution  to update systemd presets.

4) Change the definition of which events are simple (one record events) and 
compound (multiple records per event). Over the years syscall records were 
added to the simple events haphazardly. That seems to have settled down and 
we can redefine which are in which group. This is important because this 
determines when an event is complete and ready to process in ausearch,  
aureport, and auparse. This should reduce future bug reports.

5) Drop functions from libaudit python bindings that have anything to do with 
placing and removing rules in the kernel. I'd like the API to just contain 
what's needed to send audit events and query kernel status. This new binding 
would be hand written, thus possibly breaking compatibility with the swig 
generated bindinsg. Not 100% sure on that, but it might be a side effect. The 
main idea is limit the scope to reduce maintenance and future-proof kernel/
swig changes.

6) Moratorium on new arches being supported. If someone else comes along and 
really shows *sustained* support for the audit project for a while and they 
want a new arch to be supported, I might consider it. Since my work on this 
project is now a hobby, I am not inclined to make more work for my weekends.

7) Drop the autrace & auvirt programs. Does anyone actually use these? Can 
ausearch take the place of auvirt? The aim here is reduce maintenance.

Let me know what you think. I'll probably put these in a new audit-4.0 branch 
until they are complete and some testing has been done.

-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v2] TaskTracker : Simplified thread information tracker.

[Steve Grubb]

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 still a real concern enough to write articles
> > like https://access.redhat.com/solutions/165993 . TaskTracker is a
> > trivial LSM module which emits TOMOYO-like information into the audit
> > logs for better understanding of unexpected system events.
> 
> Help me understand why all of this information isn't already available
> via some combination of Audit and TOMOYO, or simply audit itself?

Usually when you want this kind of information, you are investigating an 
incident. You wouldn't place a syscall audit for every execve and then 
reconstruct the call chain from that. In the case of long running daemons, 
the information could have been rotated away. But typically you want to see 
what the entry point is. A sudden shell from bind would be suspicious while a 
shell from sshd is not.

-Steve

> In the case of an audit-only design you would likely need to do some
> processing of the audit log to determine the full historical process
> tree of the process being killed, but all of the information should be
> there if you configure audit properly.  I'm less familiar with TOMOYO,
> but your comment about this LSM recording "TOMOYO-like" information
> makes me believe that TOMOYO already records this information.




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v2] TaskTracker : Simplified thread information tracker.

[Steve Grubb]

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 would be a process label. and there is already a
> > precedent for what fields belong in a syscall record.
> 
> What is the definition of "a process label"? SELinux / Smack / AppArmor are
> using security_secid_to_secctx() hook for providing string data for the
> subj= field. I don't think that they are restricting characters that can
> be included. Then, what is wrong with returning subset of ASCII printable
> characters from tt_secid_to_secctx() ?

Typically the label is used for access control decisions. But processes have 
other attributes such as a list of open files. I think adding this information 
will be useful - I'm not opposed to the idea. I am just thinking about how to 
present the information where it is more useful. 



> > What I would suggest is to make a separate record: AUDIT_PROC_TREE that
> > describes process tree from the one killed up to the last known parent.
> > This way you can define your own format and SYSCALL can stay as everyone
> > expects it to look. In the EXECVE audit record, there is a precedent of
> > using agv[0]=xx argv[1]=xx argv[2]=yy  and so on. If you want to make
> > these generally parsable without special knowledge of the record format,
> > I'd suggest something like it.
> 
> Yes,
> https://lkml.kernel.org/r/201501202220.djj34834.oljohfmqoft...@i-love.saku
> RA.ne.jp used AUDIT_PROCHISTORY instead of LSM hooks, but that thread died
> there.

I do not read that mail list. AUDIT_PROC_HIST or AUDIT_PROC_CHAIN or some 
thing like that would be the better way to go. If someone wanted to see if 
they have process history for a segfault, how would they do it with the 
proposed record?

ausearch --subject sshd

That just doesn't seem right. If you had a record dedicated to this 
information, then you can do:

ausearch -m PROC_HIST

and it would give you that information. And if you had the data split up 
like: p[0]=xx p[1]=xx p[2]=yy

Then  someone could do this to make a report specific to this:

import auparser as aup
au = aup.AuParser(aup.AUSOURCE_FILE, "audit.log")

au.search_add_expression("type r= PROC_HIST", aup.AUSEARCH_RULE_CLEAR)
au.search_set_stop(aup.AUSEARCH_STOP_RECORD)
while au.search_next_event():
print("Call chain: ", end="")
while True:
print(au.interpret_field(), end = "")
if au.next_field() == False:
break
print("->", end="")

au = None
sys.exit(0)

This would be more programmer friendly.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v2] TaskTracker : Simplified thread information tracker.

[Steve Grubb]

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 triggered the event. For example, unexpected
> process termination is still a real concern enough to write articles
> like https://access.redhat.com/solutions/165993 . TaskTracker is a
> trivial LSM module which emits TOMOYO-like information into the audit
> logs for better understanding of unexpected system events.
> 
> I suggested TaskTracker about 10 years ago [1]. Compared to that time,
> security_task_alloc()/security_task_free() hooks have been revived, but
> the multiple concurrent LSM patches have not completed yet.
> 
> When I proposed TaskTracker as an LSM module [2], there was a comment that
> this module should not reuse the subj= field and instead add new fields to
> audit logs. But that thread died for unknown reason, and there is an effort
> for making it possible to enable SELinux and Smack at the same time. Thus,
> retrying as an LSM module based on an assumption that the multiple
> concurrent LSM patches will address how to share the subj= field. I think
> that passing whole history in one string is easier for those who want to
> avoid bloating audit log files to control history size and fields to
> include. Also, I think that userspace tools won't try to tokenize this
> history in order to perform more than fgrep matching.
> 
> But now that LSM people are about to require an LSM ID for registering an
> LSM module, I can't wait till it becomes possible to enable SELinux and
> Smack at the same time. I have to send TaskTracker upstream in order to
> assign an LSM ID for TaskTracker.
> 
> Link: https://marc.info/?l=linux-security-module=138547679621695 [1]
> Link:
> https://lkml.kernel.org/r/201405232144.jfb30480.ovmoosftqjh...@i-love.saku
> RA.ne.jp [2] Signed-off-by: Tetsuo Handa
> 
> ---
>  security/Kconfig   |   1 +
>  security/Makefile  |   1 +
>  security/tasktracker/Kconfig   |  24 +
>  security/tasktracker/Makefile  |   2 +
>  security/tasktracker/tasktracker.c | 160 +
>  5 files changed, 188 insertions(+)
>  create mode 100644 security/tasktracker/Kconfig
>  create mode 100644 security/tasktracker/Makefile
>  create mode 100644 security/tasktracker/tasktracker.c
> 
> diff --git a/security/Kconfig b/security/Kconfig
> index 52c9af08ad35..aea0ac2b24a1 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -194,6 +194,7 @@ source "security/yama/Kconfig"
>  source "security/safesetid/Kconfig"
>  source "security/lockdown/Kconfig"
>  source "security/landlock/Kconfig"
> +source "security/tasktracker/Kconfig"
> 
>  source "security/integrity/Kconfig"
> 
> diff --git a/security/Makefile b/security/Makefile
> index 18121f8f85cd..86ae43be3207 100644
> --- a/security/Makefile
> +++ b/security/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_SECURITY_LOCKDOWN_LSM) += lockdown/
>  obj-$(CONFIG_CGROUPS)+= device_cgroup.o
>  obj-$(CONFIG_BPF_LSM)+= bpf/
>  obj-$(CONFIG_SECURITY_LANDLOCK)  += landlock/
> +obj-$(CONFIG_SECURITY_TASKTRACKER)   += tasktracker/
> 
>  # Object integrity file lists
>  obj-$(CONFIG_INTEGRITY)  += integrity/
> diff --git a/security/tasktracker/Kconfig b/security/tasktracker/Kconfig
> new file mode 100644
> index ..6b294bf18878
> --- /dev/null
> +++ b/security/tasktracker/Kconfig
> @@ -0,0 +1,24 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config SECURITY_TASKTRACKER
> + bool "TaskTracker Support"
> + depends on SECURITY && AUDIT
> + default n
> + help
> +   This selects TaskTracker, a module which provides a thread's
> +   history for better understanding of audit logs.
> +
> +  If you enable this module, you will find history of current
> +  thread in the subj= field of audit logs in the form of
> +  name=$commname;pid=$pid;start=$MMDDhhmmss delimited by =>
> +  like an example shown below.
> +
> +  [root@localhost ~]# auditctl -a exit,always -F arch=b64 -S kill
> +  [root@localhost ~]# bash
> +  [root@localhost ~]# kill -9 $$
> +  Killed
> +  [root@localhost ~]# ausearch -sc kill
> +  
> +  time->Sun Aug  6 15:36:17 2023
> +  type=PROCTITLE msg=audit(1691303777.054:117): proctitle="(null)"
> +  type=OBJ_PID msg=audit(1691303777.054:117): opid=3787 oauid=0
> ouid=0 oses=1 ocomm="bash" +  
> type=SYSCALL
> msg=audit(1691303777.054:117): arch=c03e syscall=62 success=yes exit=0
> a0=ecb a1=9 a2=0 a3=7ffc779be760 items=0 ppid=3766 pid=3787 auid=0 uid=0
> gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1
> comm="bash" exe="/usr/bin/bash"

This is where the 

audit-3.1.2 released

[Steve Grubb]

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
- In auparse, when files are given, also consider EUID for access
- Auparse now interprets unnamed/anonymous sockets (Enzo Matsumiya)
- Disable Python bindings from setting rules due to swig bug (S. Trofimovich)
- Update all lookup tables for the 6.5 kernel
- Don't be as paranoid about auditctl -R file permissions
- In ausearch, correct subject/object search to be an and if both are given
- Adjust formats for 64 bit time_t
- Fix segfault in python bindings around the feed API
- Add feed_has_data, get_record_num, and get/goto_field_num to python bindings

There are various bugfixes, a refresh of the lookup tables for the 6.5 kernel, 
and some sprucing up of the python bindings. Speaking of which, this release 
removes the ability to set audit rules via the python bindings. That means no 
more workaround patch is needed for the swig issue.

SHA256: c0b1792d1f0a88c6f1828710509cbb987059fc68712c97669ca90eae103d287d

Please let me know if you run across any problems with this release.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Cannot disable kernel's audit system via auditctl

[Steve Grubb]

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 issue for this thread:
> https://github.com/linux-audit/audit-kernel/issues/146
> 
> The maintainer there suggested it's too difficult to debug due to eBPF
> programs + AWS's modified kernel.

I think there is data that could help decide where the problem might be. On 
one of the systems that is still logging, try running an event type report:

aureport --start yesterday --event --summary -i

This should identify what kind of event is being emitted. Based on that, it 
might point to where the problem is.

> I've resigned to asking Red Canary to support eBPF mode with `audit=0`
> kernel parameter in their Linux EDR. Let me know if you have any other
> ideas.

I'd say collecting summary information about what kind of events are being 
logged would be a good start.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Cannot disable kernel's audit system via auditctl

[Steve Grubb]

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 from the
> kernel's audit system and everything was fine. However, when we switched
> cfsvcd to gathering data from eBPF instead, we noticed that the kernel
> ring buffer was flooded with audit messages. This is because
> cfsvcd.service now stops auditd.service, but leaves the kernel audit
> system enabled.
> 
> I've mitigated this issue by manually running `# auditctl -e 0` on our
> hosts (via Puppet). However, I'm running into a strange issue where _some_
> hosts (~0.5%) are still logging all audit events to the kernel ring buffer
> even after I have disabled the audit system via `# auditctl -e 0`. A `#
> auditctl -s` run shows `enabled 0`, yet audit logs continue to flood the
> kernel ring buffer.
> 
> I'm running Linux kernel 5.4.0-1063-aws on Ubuntu 18.04 with auditctl
> v2.8.2. `systemd-journald-audit.socket` is masked & inactive, `
> auditd.service` is disabled & inactive.
> 
> I cannot entirely disable the audit system via a kernel parameter because
> Red Canary Linux EDR fails to start cfsvcd.service as it fails to run some
> auditctl command due to no audit support in the kernel:
> 
> Jun 28 20:41:04 systemd[1]: Started Canary Forwarder Service.
> 
> > Jun 28 20:41:04 cfsvcd[105781]: Found config file at path
> > '"/opt/redcanary/config.json"', continuing execution...
> > Jun 28 20:41:12 cfsvcd[105781]: component: Sentry
> > Jun 28 20:41:12 cfsvcd[105781]:  Jun 28 20:41:12.055 INFO Initializing
> > Sentry Config { version: "1.4.17.release.[...]", https_proxy: None,
> > extra_tags: [("telemetry.source", "eBPF")], logging_enabled: true,
> > metrics_enabled: true, [...]}
> > Jun 28 20:41:12 cfsvcd[105781]: Failed to setup or configure host system:
> > Linux Audit watcher failure: Netlink Error: IO Error: Protocol not
> > supported (os error 93)
> > Jun 28 20:41:12 cfsvcd[105781]: Received stop. Exiting
> > unix::wait_for_signal. Signal: 0, done.is_signaled(): true
> > Jun 28 20:41:12 cfsvcd[105781]: Joining async_agent_thread
> > Jun 28 20:41:13 cfsvcd[105781]: Attempting to stop subscriber (Ebpf).
> > Jun 28 20:41:13 cfsvcd[105781]: Shutting down due to termination signal
> > [...]
> > Jun 28 20:41:15 cfsvcd[105781]: Subscriber stopped.
> > Jun 28 20:41:15 auditctl[106733]: Error - audit support not in kernel
> > Jun 28 20:41:15 auditctl[106733]: Cannot open netlink audit socket
> > Jun 28 20:41:15 systemd[1]: cfsvcd.service: Service hold-off time over,
> > scheduling restart.
> > Jun 28 20:41:15 systemd[1]: cfsvcd.service: Scheduled restart job,
> > restart
> > counter is at 301.
> > Jun 28 20:41:15 systemd[1]: Stopped Canary Forwarder Service.
> 
> Here's the unit file for cfsvcd.service:
> > [Unit]
> > Description=Canary Forwarder Service
> > 
> > DefaultDependencies=no
> > After=local-fs.target systemd-tmpfiles-setup.service auditd.service
> > Before=sysinit.target shutdown.target
> > # Replace the auditd service if it is running
> > Conflicts=auditd.service shutdown.target
> > 
> > [Service]
> > WorkingDirectory=/opt/redcanary
> > ExecStart=/opt/redcanary/cfsvcd
> > ExecStopPost=-/sbin/auditctl -D
> > Restart=always
> > TimeoutSec=15
> > 
> > [Install]
> > WantedBy=multi-user.target
> 
> Is this a known issue?

Not really. But this is a new capability. If you run auditctl -D, does it go 
away? Have any of the systems been setup with auditctl -e 2? This makes the 
configuration immutable.

-Steve

> Is there a workaround to stop the logging to the
> kernel ring buffer? Is there any more information I can provide to help
> debug?



--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Comprehensive Documentation on the Linux Audit Framework

[Steve Grubb]

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 mismatch and it might not matter.

> The reason I'm asking for this is that I'm trying to provide auditing for
> files of a specific type and I'm trying to understand how would that work.

The way the audit system works is there is a rule engine in the kernel. User 
space loads the rules and and listens for events. The kernel does all the 
work. This rule matching can be done by a limited set of attributes which for 
a file would be path, kind of access, who is accessing it, program accessing 
it, portions of se linux labeling, and a few other things.

You cannot match by type or anything that looks like a glob. You can arrange 
them in a directory and watch the whole directory. You can create a script 
that looks for files of a certain type and load rules specifically for them 
into the kernel (with a specific key so you can find them later). Or you can 
plug into auditd as a plugin and filter the events and write them to your own 
log.

There might be some other approaches such as using fanotify and filtering 
those events yourself.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Comprehensive Documentation on the Linux Audit Framework

[Steve Grubb]

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 of the userspace portion of code, it mentions 
that there is a netlink api. It simply listens and writes what it finds to 
disk. Auditing must be enabled and you need to set the pid in the kernel and 
then listen for events. There is no extensive documentation - the code is the 
documentation to the low level API.

There is also a best effort multicast netlink api that systemd-journald uses 
to get events out of the kernel.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Auditd doesn't receive syscalls after installation for the current shell.

[Steve Grubb]

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: $ apt install auditd
> step #2: $ auditctl -a always,exit -F arch=b64 -S openat,renameat2,unlinkat
> step #3: $ echo t>delme;echo t2>>delme;cat delme;mv delme d;mv d
> delme;rm delme
> step #4: $ service auditd stop
> step #5: $ ausearch -f delme
> 
> There are syscalls from /usr/bin/cat, /usr/bin/mv, /usr/bin/rm but there
> are no any syscalls (openat expected)
> for /usr/bin/bash (current shell process) for the file.
> 
> If step #3 is performed from another tty, then openat syscalls
> (CREATE for the first echo and NORMAL for the second one)
> is logged for the /usr/bin/bash process.
> 
> `uname -a` returns: Linux grin-vb-ubuntu-22-0-4 5.19.0-41-generic
> #42~22.04.01-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 18 17:40:00 UTC 2 x86_64
> x86_64 x86_64 GNU/Linux
> 
> Should I open an issue for the case at
> https://github.com/linux-audit/audit-kernel ?

Are you booting with audit=1 ? If not, the install process and any before it 
are not auditable. You will only get events for processes started after audit 
enabled = 1.

-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: No more report of quantity of rules successfully loaded

[Steve Grubb]

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 service (with -e 1 set) that I would 100% of the time get a report
> in /var/log/messages about the quantity of rules that successfully loaded.

It has never done that unless someone else has a patch they did not send 
upstream.

> I could compare that to my unified rules file
> (/etc/audit/rules.d/Unified.rules - for a reference) and strip out the
> typical for auditd Control rules (-D, -e 1, -f 1, -b, -r, for examples) and
> then assess if I had the full set of files loaded or not.
> 
> With this implementation of auditd, on version 3.0.7-4, I am not getting
> those results anymore.
> Am I looking in the wrong place, because for me this is important
> information?

It has never done that. auditctl -D gives the output of auditctl -s as a 
convenience. But auditctl -s has never reported how many rules are loaded. I 
don't think the kernel has a counter. It has a variable for if any rules are 
loaded, but not the quantity.

> Yes, I know that I can also manually execute "auditctl -l  | wc -l" and get
> that information  too, but I was wondering if this is planned or if I am
> looking in the wrong place, or what to do.

It has never done that and is not planned.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: What STIG audit rule picks up type=SOFTWARE_UPDATE events?

[Steve Grubb]

Hello,

On Wednesday, May 17, 2023 1:59:42 AM EDT Claire Stafford wrote:
> For some reason I had the idea that there were other software related
> events - no wonder I couldn't find them!  Really they ought to at least
> indicate if the install is a new or upgraded package, also 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 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 in turn has a plugin, rpm-plugin-
> > audit, which generates the audit events.
> > 
> >> A very quick scan of the rpm source code doesn't reveal anything.
> > 
> > https://github.com/rpm-software-management/rpm/blob/master/plugins/audit.
> > c
> > 
> > -Steve
> > 
> >> On 5/14/23 14:46, Steven Grubb wrote:
> >>> Hello,
> >>> 
> >>> 
> >>> On Fri, May 12, 2023 at 5:23 PM Wieprecht, Karen M.
> >>> 
> >>>   wrote:
> >>>  All,
> >>>  
> >>>  Do you happen to know which if the standard STIG rules is picking
> >>>  up   type=SOFTWARE_UPDATE events on RHEL 7 and 8 ?
> >>> 
> >>> None. rpm has been altered to produce these much the same as pam
> >>> produces login events. It was too tricky to tell the intent to update
> >>> vs querying the rpm database. And you have no way to answer the
> >>> question about success without originating from inside rpm itself. I
> >>> don't think any external rules can meet all requirements imposed by
> >>> OSPP, which the STIG audit rules are loosely based on.
> >>> 
> >>> -Steve
> >>> 
> >>>I’m trying to figure out if we missed one of these rules on an
> >>>  
> >>>  Ubuntu 20 system we are configuring  or if maybe the audit
> >>>  subsystem implementation on that system doesn’t pick up all of the
> >>>  same record types as we get on our RHEL boxes. I realized when I
> >>>  started looking at this that it’s not easy to determine which
> >>>  audit rule is picking up a particular event if it’s not one of the
> >>>  rule that has a key associated with it.
> >>>  
> >>>  As a possible alternative,   I ran across a sample audit.rules
> >>>  
> >>>   list here GitHub - Neo23x0/auditd: Best Practice Auditd
> >>>  
> >>>  Configuration<https://github.com/Neo23x0/auditd>   (actual rules
> >>>  file is here: auditd/audit.rules at master · Neo23x0/auditd ·
> >>>  GitHub
> >>>  <https://github.com/Neo23x0/auditd/blob/master/audit.rules>) which
> >>>  included some software management rules that don’t appear to be
> >>>  
> >>>   part of the standard “30-stig.rules” .
> >>>  
> >>>  If the standard STIG rules don’t pick up  type=SOFTWARE_UPDATE
> >>>  events on Ubuntu20,  I might add some of these , so I was hoping
> >>>  to have a quick sanity check on whether these look like
> >>>  appropriate alternatives.  Any recommendations or comments
> >>>  regarding these sample rules would be much appreciated.  Basically
> >>>  it looks to me like they are just setting watches for anyone
> >>>  
> >>>   executing these various commands, which shouldn’t cause to much
> >>>  
> >>>  noise in the logs except maybe when we are patching which is one
> >>>  of the continuous monitoring items I  need to be able to confirm.
> >>>  
> >>>  Thanks much!
> >>>  
> >>>  Karen Wieprecht
> >>>  
> >>>  # Software Management
> >>>  -
> >>>  
> >>>  # RPM (Redhat/CentOS)
> >>>  
> >>>  -w /usr/bin/rpm -p x -k software_mgmt
> >>>  
> >>>  -w /usr/bin/yum -p x -k software_mgmt
> >>>  
> >>>  # DNF (Fedora/RedHat 8/CentOS 8)
> >>> 

Re: What STIG audit rule picks up type=SOFTWARE_UPDATE events?

[Steve Grubb]

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 in turn has a plugin, rpm-plugin-
audit, which generates the audit events.

> A very quick scan of the rpm source code doesn't reveal anything.

https://github.com/rpm-software-management/rpm/blob/master/plugins/audit.c

-Steve

> On 5/14/23 14:46, Steven Grubb wrote:
> > Hello,
> > 
> > 
> > On Fri, May 12, 2023 at 5:23 PM Wieprecht, Karen M.
> > 
> >  wrote:
> > All,
> > 
> > Do you happen to know which if the standard STIG rules is picking
> > up   type=SOFTWARE_UPDATE events on RHEL 7 and 8 ?
> > 
> > None. rpm has been altered to produce these much the same as pam
> > produces login events. It was too tricky to tell the intent to update
> > vs querying the rpm database. And you have no way to answer the
> > question about success without originating from inside rpm itself. I
> > don't think any external rules can meet all requirements imposed by
> > OSPP, which the STIG audit rules are loosely based on.
> > 
> > -Steve
> > 
> >   I’m trying to figure out if we missed one of these rules on an
> > Ubuntu 20 system we are configuring  or if maybe the audit
> > subsystem implementation on that system doesn’t pick up all of the
> > same record types as we get on our RHEL boxes. I realized when I
> > started looking at this that it’s not easy to determine which
> > audit rule is picking up a particular event if it’s not one of the
> > rule that has a key associated with it.
> > 
> > As a possible alternative,   I ran across a sample audit.rules
> >  list here GitHub - Neo23x0/auditd: Best Practice Auditd
> > Configuration   (actual rules
> > file is here: auditd/audit.rules at master · Neo23x0/auditd ·
> > GitHub
> > ) which
> > included some software management rules that don’t appear to be
> >  part of the standard “30-stig.rules” .
> > 
> > If the standard STIG rules don’t pick up  type=SOFTWARE_UPDATE
> > events on Ubuntu20,  I might add some of these , so I was hoping
> > to have a quick sanity check on whether these look like
> > appropriate alternatives.  Any recommendations or comments
> > regarding these sample rules would be much appreciated.  Basically
> > it looks to me like they are just setting watches for anyone
> >  executing these various commands, which shouldn’t cause to much
> > noise in the logs except maybe when we are patching which is one
> > of the continuous monitoring items I  need to be able to confirm.
> > 
> > Thanks much!
> > 
> > Karen Wieprecht
> > 
> > # Software Management
> > -
> > 
> > # RPM (Redhat/CentOS)
> > 
> > -w /usr/bin/rpm -p x -k software_mgmt
> > 
> > -w /usr/bin/yum -p x -k software_mgmt
> > 
> > # DNF (Fedora/RedHat 8/CentOS 8)
> > 
> > -w /usr/bin/dnf -p x -k software_mgmt
> > 
> > # YAST/Zypper/RPM (SuSE)
> > 
> > -w /sbin/yast -p x -k software_mgmt
> > 
> > -w /sbin/yast2 -p x -k software_mgmt
> > 
> > -w /bin/rpm -p x -k software_mgmt
> > 
> > -w /usr/bin/zypper -k software_mgmt
> > 
> > # DPKG / APT-GET (Debian/Ubuntu)
> > 
> > -w /usr/bin/dpkg -p x -k software_mgmt
> > 
> > -w /usr/bin/apt -p x -k software_mgmt
> > 
> > -w /usr/bin/apt-add-repository -p x -k software_mgmt
> > 
> > -w /usr/bin/apt-get -p x -k software_mgmt
> > 
> > -w /usr/bin/aptitude -p x -k software_mgmt
> > 
> > -w /usr/bin/wajig -p x -k software_mgmt
> > 
> > -w /usr/bin/snap -p x -k software_mgmt
> > 
> > # PIP(3) (Python installs)
> > 
> > -w /usr/bin/pip -p x -k T1072_third_party_software
> > 
> > -w /usr/local/bin/pip -p x -k T1072_third_party_software
> > 
> > -w /usr/bin/pip3 -p x -k T1072_third_party_software
> > 
> > -w /usr/local/bin/pip3 -p x -k T1072_third_party_software
> > 
> > # npm
> > 
> > ## T1072 third party software
> > 
> > ## https://www.npmjs.com
> > 
> > ## https://docs.npmjs.com/cli/v6/commands/npm-audit
> > 
> > -w /usr/bin/npm -p x -k T1072_third_party_software
> > 
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://listman.redhat.com/mailman/listinfo/linux-audit
> > 
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://listman.redhat.com/mailman/listinfo/linux-audit




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: sending audit logs only to audit.log via rsyslog

[Steve Grubb]

On Wednesday, May 10, 2023 11:51:04 AM EDT kathy lyons wrote:
> Great - so I don't need the line below in my rsyslog.conf file?
> 
>  audit.*   ~/var/log/audit/audit.log

No that's not needed. The whole problem is caused by journald. It connects to 
a best effort multicast socket to get audit events. It then writes them to 
rsyslog in addition to the journal. Meanwhile, auditd connects to the real 
netlink interface and grabs events from the kernel and writes them to disk 
itself. No one needs 3 separate audit logs.

After masking journald'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 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")
> > > module(load="imklog")
> > > module(load="imjournal")
> > > 
> > > global(net.enableDNS="off" workDirectory=/var/spool/rsyslog"
> > > 
> > > maxMessageSize="128k")
> > > 
> > >$IncludeConfig /etc/rsyslog.d/*.conf
> > >$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
> > >   
> > >   # rules
> > >   
> > > audit.* ~/var/log/audit/audit.log
> > > auth.warning;authpriv.info   ~/var/log/auth.log
> > > *.*;auth,authpriv.none   ~/var/log/syslog
> > > cron.info   ~/var/log/cron.log
> > > daemon.info~/var/log/daemon.log
> > > kern.*  ~/var/log/kern.log
> > > user.info ~/var/log/user.log
> > 
> > The thing that is writing them to rsyslog is systemd-journald. You can
> > stop
> > this by running:
> > 
> > systemctl mask systemd-journald-audit.socket
> > systemctl stop systemd-journald-audit.socket
> > 
> > Then you will only have logs written to the audit log.
> > 
> > -Steve




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: sending audit logs only to audit.log via rsyslog

[Steve Grubb]

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")
> module(load="imklog")
> module(load="imjournal")
> 
> global(net.enableDNS="off" workDirectory=/var/spool/rsyslog"
> maxMessageSize="128k")
> 
>$IncludeConfig /etc/rsyslog.d/*.conf
>$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
> 
>   # rules
> audit.* ~/var/log/audit/audit.log
> auth.warning;authpriv.info   ~/var/log/auth.log
> *.*;auth,authpriv.none   ~/var/log/syslog
> cron.info   ~/var/log/cron.log
> daemon.info~/var/log/daemon.log
> kern.*  ~/var/log/kern.log
> user.info ~/var/log/user.log

The thing that is writing them to rsyslog is systemd-journald. You can stop 
this by running:

systemctl mask systemd-journald-audit.socket
systemctl stop systemd-journald-audit.socket

Then you will only have logs written to the audit log.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Can AUDIT_LIST_RULES causes kthreadd-spam?

[Steve Grubb]

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 name, but
> it is dump_stack_print_info() that shows pid and comm name.
> 
> > As far as I can see, it's the exit of `sendto` syscall.
> > It seems that the kernel just creates a new kthreadd for each sendto
> > syscall. But I think that I'm wrong and just missing something.
> 
> Yes, sendto() on netlink socket calls netlink_sendmsg().
> For some reason, audit_send_reply() is called for many times.
> audit_send_reply() is called by audit_receive_msg() for the following
> types.
> 
>   AUDIT_GET
>   AUDIT_SIGNAL_INFO
>   AUDIT_TTY_GET
>   AUDIT_GET_FEATURE

The audit userspace always adds NLM_F_ACK to any netlink communication to 
make sure it did not get discarded before it arrived. It has done this since 
before I started working on audit code.

-Steve

> Would you re-caputure with
> 
> - dump_stack();
> + pr_info("%s %s:%d type=%d\n", __func__, current->comm, current->pid,
> type);
> 
> ?
> 
> Regardless of the result of re-caputure, it seems there is no switch that
> can prevent audit_send_reply() from calling
> kthread_run(audit_send_reply_thread).
> 
> But since kthreadd runs with PID=2 and PPID=0, you might be able to use
> PID=2 and/or PPID=0 in your rules in order to let kernel audit subsystem
> ignore kthreadd. (I can't test because I haven't found how to reproduce
> audit_receive_msg() in my environment...)
> 
> # cat /proc/2/status
> Name:   kthreadd
> Umask:  
> State:  S (sleeping)
> Tgid:   2
> Ngid:   0
> Pid:2
> PPid:   0
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://listman.redhat.com/mailman/listinfo/linux-audit




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: "service auditd start" fails inside a container

[Steve Grubb]

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 don't know what use it would 
be to containerize it.

And if you are asking if auditd can audit events in a container, I think that 
answer is also no.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

audit-3.1.1 released

[Steve Grubb]

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 auparse to better handle corrupt logs
- Fix a CFLAGS propogation problem in the common directory
- Move the audispd af_unix plugin to a standalone program

The most relevant thing to packagers is to know about the last item above. 
Due to a timing race in the af_unix plugin, it was possible to get auditd to 
not accept any more af_unix connections. You have to be root to connect, so 
this is nothing a normal user could trigger. The fix was to pull the af_unix 
plugin out of auditd to be a standalone program.

auditctl --signal can now use: stop, reload, rotate, resume, and state. This 
can be used where people want to stop using the service command.

One last thing to mention, ausearch/auparse have been hardened to better deal 
with corrupted logs.

SHA256: 46e46b37623cce09e6ee134e78d668afc34f4e1c870c853ef12e4193078cfe87

Please let me know if you run across any problems with this release.

-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: small patch for issue with rules that have been (incorrecly) copied from Windows

[Steve Grubb]

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

Re: Auditing nftables changes

[Steve Grubb]

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.

There are simple events which are one line and compound events which are 
multiple lines - called records. The simple events tend to be hardwired and 
not optional. For example, logins are hardwired; kernel config changes are 
hardwired; authentication is hardwired.

The compound events tend to be related to audit rules (but not always). When 
the rule triggers, the syscall triggering the recording travels around 
different parts of the kernel. As it does so, there is code that observes and 
records different attributes of what it's doing. It may record the path, the 
socket, the command line, arguments of the syscall, etc. Then when the 
syscall finishes, the different observations are lumped together with the same 
serial number and output to the audit daemon.

The events originating from a rule can optionally have a key. This is to 
allow grouping of multiple rules that meet the same requirement. Simple 
events never have a key.

There are a couple presentations here that may help understand the audit 
system:
https://people.redhat.com/sgrubb/audit/

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: How to define audit rule for one bit *not* set for a syscall argument?

[Steve Grubb]

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)(void *), void *stack, int flags, void *arg, ...
>  /* pid_t *parent_tid, void *tls, pid_t *child_tid */ );
> 
> From man page of auditctl, -F option build a rule file: name, operation,
> value.
> -F [n=v | n!=v | nv | n<=v | n>=v | n | n&=v]
> 
> I can understand that, the n (Audit_bitmask) means any bit of a bitmast
> is set, and the n&=v (Audit_bittest) means all bits of a bitmask are set.
> 
> While my question is, how to build a rule which means "none of bit of a
> bitmask is set", i.e. ( ! n&=v ). If the current audit comparator dosen't
> support this, can we add the support in furture?

The comparator does not support this. This is a corner case in which this is 
the first time someone ever needed it.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Key based rate limiter (audit_set_rate_limit)

[Steve Grubb]

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 contribute something similar to the
> Auditd Kernel repository?

I'm not Paul...but I think what you are proposing is a per rule service
class. Always and best effort where best effort gets discarded when the
backlog is above some heuristic. And rules not saying anything are assumed 
always for backwards compatibility. The main issue is that rules are defined
here:

https://github.com/linux-audit/audit-kernel/blob/main/include/uapi/linux/
audit.h#L510

There just really isn't room to add more thinkgs without some userspace API 
problem. (This would definitely need a feaure bitmap so user space can make 
sense of it.)

I suppose we could declare some bits in flags to carry this meaning? Anyways, 
maybe others might chime in to say if they want/need such a feature.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: audit userspace problems with io_uring async ops

[Steve Grubb]

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 parsing URINGOP and DM_CTRL records. Btw, 
has anyone ever seen a DM_CTRL record? I don't think they are following our 
guidelines.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: audit userspace problems with io_uring async ops

[Steve Grubb]

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_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 events it doesn't display async io_uring events (URINGOP
> > records/events without an associated SYSCALL record/event).  Take the
> > following snippet from /var/log/audit/audit.log ...
> 
> Hi Steve,
> 
> Before I start working around this in the audit-testsuite I just
> wanted to check and see if you already had a fix for ausearch?

Thanks for the bug report. I have been out for the last 8 days and now have 
~3600 unread emails. I will try look into this tomorrow.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Clarification Around File System Auditing

[Steve Grubb]

Hello,

On Tuesday, February 14, 2023 3:55:58 PM EST Amjad Gabbar wrote:
> Thanks for the reply.
> I was trying to evaluate the same via Flamegraphs and what I noticed was
> that :
> 
> 1. Despite deleting all rules (auditctl -D), there were still calls to
> audit_filter_syscall() on each syscall. I assume this is because syscall
> auditing is enabled and despite no rules, there still will be some
> performance impact and calls to syscall filtering functions on each
> syscall.

Yes.

> 2. For a single watch rule as well without any syscall rules, I could see
> calls to audit_filter_syscall() followed by audit_filter_rules() for
> unrelated syscalls such as futex() and recvmsg() - not present in
> include/asm-generic/audit_*.h
> Why would these functions be called for a single watch rule for syscalls
> unrelated to the permissions?

If auditing is enabled, it will go into the syscall filter for *any* syscall. 
It will go into __audit_syscall_exit for every syscall. If there is an audit 
context, it will go into audit_filter_syscall. The documentation in the 
comments above these functions is informative.

My guess is that this code path 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: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
> > > auditing, even though both make use of syscall exits for their
> > 
> > evaluation.
> > 
> > > From the manpage - "Unlike most syscall auditing rules, watches do not
> > > impact performance based on the number of rules sent to the kernel."
> > > 
> > > From a previous thread, I found this excerpt regarding file watch rules
> > 
> > vs
> > 
> > > sycall rules -
> > > 
> > > "The reason it doesn't have performance impact like normal syscall
> > > rules
> > 
> > is
> > 
> > > because it gets moved to a list that is not evaluated every syscall. A
> > > normal syscall rule will get evaluated for every syscall because it has
> > 
> > to
> > 
> > > see if the syscall number is of interest and then it checks the next
> > > rule."
> > > 
> > > Based on this I had a couple of questions:
> > > 
> > > For normal syscall rules, the evaluation happens as
> > > __audit_syscall_exit
> > > <https://elixir.bootlin.com/linux/v6.1.10/C/ident/__audit_syscall_exit>
> > > calls audit_filter_syscall
> > > (https://elixir.bootlin.com/linux/v6.1.10/source/kernel/auditsc.c#L841)
> > > 
> > > Here, we check if the syscall is of interest or not in the
> > > audit_in_mask
> > > <https://elixir.bootlin.com/linux/v6.1.10/C/ident/audit_in_mask>
> > 
> > function.
> > 
> > > Only if the syscall is of interest do we proceed with examining the
> > > task
> > > and return on the first rule match.
> > > 
> > > 1. What is the process or code path for watch rules?
> > > audit_filter_syscall
> > > <https://elixir.bootlin.com/linux/v6.1.10/C/ident/audit_filter_syscall>
> > 
> > is
> > 
> > > called for watch rules as well. Then how is it that these are not
> > > called
> > > for every syscall? Could you point me to the code where the evaluation
> > > happens only once?
> > 
> > There is a file, kernel/audit_watch.c, that implements the interface
> > between
> > audit and fsnotify. You would want to learn how fsnotify works to
> > understand
> > how it avoids the syscall filter.
> > 
> > > 2. Also, do file watches only involve the open system call family
> > > (open,
> > > openat etc). The man page implies the same, so just wanted to confirm.
> > > 
> > > I assume -w /etc -p wa is the same as -a always,exit -S open -S openat
> > > -F
> > > dir=/etc?
> > 
> > It depends on the flag passed for perm as to what syscall it wants. See:
> > 
> > include/asm-generic/audit_*.h
> > 
> > -Steve




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v2] io_uring,audit: don't log IORING_OP_MADVISE

[Steve Grubb]

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 pattern
> > > > for file and memory respectively.  Skip them.
> > > 
> > > You forgot to update the first sentence in the commit description :/
> > 
> > I didn't forget.  I updated that sentence to reflect the fact that the
> > two should be treated similarly rather than differently.
> 
> Ooookay.  Can we at least agree that the commit description should be
> rephrased to make it clear that the patch only adjusts madvise?  Right
> now I read the commit description and it sounds like you are adjusting
> the behavior for both fadvise and madvise in this patch, which is not
> true.
> 
> > > I'm still looking for some type of statement that you've done some
> > > homework on the IORING_OP_MADVISE case to ensure that it doesn't end
> > > up calling into the LSM, see my previous emails on this.  I need more
> > > than "Steve told me to do this".
> > > 
> > > I basically just want to see that some care and thought has gone into
> > > this patch to verify it is correct and good.
> > 
> > Steve suggested I look into a number of iouring ops.  I looked at the
> > description code and agreed that it wasn't necessary to audit madvise.
> > The rationale for fadvise was detemined to have been conflated with
> > fallocate and subsequently dropped.  Steve also suggested a number of
> > others and after investigation I decided that their current state was
> > correct.  *getxattr you've advised against, so it was dropped.  It
> > appears fewer modifications were necessary than originally suspected.
> 
> My concern is that three of the four changes you initially proposed
> were rejected, which gives me pause about the fourth.  You mention
> that based on your reading of madvise's description you feel auditing
> isn't necessary - and you may be right - but based on our experience
> so far with this patchset I would like to hear that you have properly
> investigated all of the madvise code paths, and I would like that in
> the commit description.

I think you're being unnecessarily hard on this. Yes, the commit message 
might be touched up. But madvise is advisory in nature. It is not security 
relevant. And a grep through the security directory doesn't turn up any 
hooks.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

audit-3.1 released

[Steve Grubb]

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_syscallbyname_data work correctly outside of auditctl
- Add new record types
- Add io_uring support
- Add support for new FANOTIFY record fields
- Add keyword, this-hour, to ausearch/report start/end options
- Add Requires.private to audit.pc file
- Try to interpret OPENAT2 fields correctly

ProtectControlGroups in auditd.service was preventing people from placing 
rules on /proc, so it's now off by default. The checks on the exclude filter 
were not matching the checks that kernel does. The checks were updated. 
io_uring support was added as was support for translating the new fields in 
the FANOTIFY record. The interpretation of the mode field in the OPENAT2 
record was broken because it was expected to be in hex format like everywhere 
else, but instead it is decimal. That should be corrected.

SHA256: b5cf3cdabb2786c08b1de3599a3b1a547e55f7a9f9c1eb2078f5b44cf44e8378

Please let me know if you run across any problems with this release.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v7 0/3] fanotify: Allow user space to pass back additional audit info

[Steve Grubb]

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 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 additional context for
> > > > > the
> > > > > decision. If this information were available in the audit trail,
> > > > > policy
> > > > > writers can close the loop on debugging policy. Also, if this
> > > > > additional
> > > > > information were available, it would enable the creation of tools
> > > > > that
> > > > > can suggest changes to the policy similar to how audit2allow can
> > > > > help
> > > > > refine labeled security.
> > > > > 
> > > > > This patchset defines a new flag (FAN_INFO) and new extensions that
> > > > > define additional information which are appended after the response
> > > > > structure returned from user space on a permission event.  The
> > > > > appended
> > > > > information is organized with headers containing a type and size
> > > > > that
> > > > > can be delegated to interested subsystems.  One new information
> > > > > type is
> > > > > defined to audit the triggering rule number.
> > > > > 
> > > > > A newer kernel will work with an older userspace and an older
> > > > > kernel
> > > > > will behave as expected and reject a newer userspace, leaving it up
> > > > > to
> > > > > the newer userspace to test appropriately and adapt as necessary. 
> > > > > This
> > > > > is done by providing a a fully-formed FAN_INFO extension but
> > > > > setting the
> > > > > fd to FAN_NOFD.  On a capable kernel, it will succeed but issue no
> > > > > audit
> > > > > record, whereas on an older kernel it will fail.
> > > > > 
> > > > > The audit function was updated to log the additional information 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_trust=2 obj_trust=2> > > 
> > > > Thanks! I've applied this series to my tree.
> > > 
> > > While I think this version of the patchset is fine, for future
> > > reference it would have been nice if you had waited for my ACK on
> > > patch 3/3; while Steve maintains his userspace tools, I'm the one
> > > responsible for maintaining the Linux Kernel's audit subsystem.
> > 
> > Aha, I'm sorry for that. I had the impression that on the last version of
> > the series you've said you don't see anything for which the series should
> > be respun so once Steve's objections where addressed and you were silent
> > for a few days, I thought you consider the thing settled... My bad.
> 
> That's understandable, especially given inconsistencies across
> subsystems.  If it helps, if I'm going to ACK something I make it
> explicit with a proper 'Acked-by: ...' line in my reply; if I say
> something looks good but there is no explicit ACK, there is usually
> something outstanding that needs to be resolved, e.g. questions,
> additional testing, etc.
> 
> In this particular case I posed some questions in that thread and
> never saw a reply with any answers, hence the lack of an ACK.  While I
> think the patches were reasonable, I withheld my ACK until the
> questions were answered ... which they never were from what I can
> tell, we just saw a new patchset with changes.
> 
> /me shrugs

Paul,

I reread the thread. You only had a request to change if/else to a switch 
construct only if there was a respin for the 3F. You otherwise said get 
Steve's input and the 3F borders on being overly clever. Both were addressed. 
If you had other questions that needed answers on, please restate them to 
expedite approval of this set of patches. As far as I can tell, all comments 
are addressed.

Best,
-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v7 0/3] fanotify: Allow user space to pass back additional audit info

[Steve Grubb]

Hello Richard,

On Friday, February 3, 2023 4:35:13 PM EST 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 additional context for the
> decision. If this information were available in the audit trail, policy
> writers can close the loop on debugging policy. Also, if this additional
> information were available, it would enable the creation of tools that
> can suggest changes to the policy similar to how audit2allow can help
> refine labeled security.
> 
> This patchset defines a new flag (FAN_INFO) and new extensions that
> define additional information which are appended after the response
> structure returned from user space on a permission event.  The appended
> information is organized with headers containing a type and size that
> can be delegated to interested subsystems.  One new information type is
> defined to audit the triggering rule number.
> 
> A newer kernel will work with an older userspace and an older kernel
> will behave as expected and reject a newer userspace, leaving it up to
> the newer userspace to test appropriately and adapt as necessary.  This
> is done by providing a a fully-formed FAN_INFO extension but setting the
> fd to FAN_NOFD.  On a capable kernel, it will succeed but issue no audit
> record, whereas on an older kernel it will fail.

I have taken the patches and built a new kernel. Everything looks good to me 
on the audit side. It's acting as expected. You can put me down for an ACK or 
tested-by or whatever is appropriate.

-Steve

> The audit function was updated to log the additional information 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_trust=2
> obj_trust=2
> 
> changelog:
> v1:
> - first version by Steve Grubb 
> Link: https://lore.kernel.org/r/2042449.irdbgypaU6@x2
> 
> v2:
> - enhancements suggested by Jan Kara 
> - 1/3 change %d to %u in pr_debug
> - 2/3 change response from __u32 to __u16
> - mod struct fanotify_response and fanotify_perm_event add extra_info_type,
> extra_info_buf - extra_info_buf size max FANOTIFY_MAX_RESPONSE_EXTRA_LEN,
> add struct fanotify_response_audit_rule - extend debug statements
> - remove unneeded macros
> - [internal] change interface to finish_permission_event() and
> process_access_response() - 3/3 update format of extra information
> - [internal] change interface to audit_fanotify()
> - change ctx_type= to fan_type=
> Link: https://lore.kernel.org/r/cover.1651174324.git@redhat.com
> 
> v3:
> - 1/3 switch {,__}audit_fanotify() from uint to u32
> - 2/3 re-add fanotify_get_response switch case FAN_DENY: to avoid
> unnecessary churn - add FAN_EXTRA flag to indicate more info and break
> with old kernel - change response from u16 to u32 to avoid endian issues
> - change extra_info_buf to union
> - move low-cost fd check earlier
> - change FAN_RESPONSE_INFO_AUDIT_NONE to FAN_RESPONSE_INFO_NONE
> - switch to u32 for internal and __u32 for uapi
> Link: https://lore.kernel.org/all/cover.1652730821.git@redhat.com
> 
> v4:
> - scrap FAN_INVALID_RESPONSE_MASK in favour of original to catch invalid
> response == 0 - introduce FANOTIFY_RESPONSE_* macros
> - uapi: remove union
> - keep original struct fanotify_response, add fan_info infra starting with
> audit reason - uapi add struct fanotify_response_info_header{type/pad/len}
> and struct fanotify_response_info_audit_rule{hdr/rule} - rename fan_ctx=
> to fan_info=, FAN_EXTRA to FAN_INFO
> - change event struct from type/buf to len/buf
> - enable multiple info extensions in one message
> - hex encode fan_info in __audit_fanotify()
> - record type FANOTIFY extended to "type=FANOTIFY
> msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F" Link:
> https://lore.kernel.org/all/cover.1659996830.git@redhat.com
> 
> v5:
> - fixed warnings in p2/4 and p3/4 found by 
> - restore original behaviour for !FAN_INFO case and fanotify_get_response()
> - rename member audit_rule to rule_number
> - eliminate memory leak of info_buf on failure (no longer dynamic)
> - rename buf:info, count:info_len, c:remain, ib:infop
> - fix pr_debug
> - return -ENOENT on FAN_INFO and fd==FAN_NOFD to signal new kernel
> - fanotify_write() remove redundant size check
> - add u32 subj_trust obj_trust fields with unknown value "2"
> - split out to helper process_access_response_info()
> - restore finish_permission_event() response_struct

Re: audit library license

[Steve Grubb]

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.so are created following source codes.
> 
> In 'auparse/Makefile.am'
> 
> AM_CPPFLAGS = -I. -I${top_srcdir} -I${top_srcdir}/src -I${top_srcdir}/lib
> -I${top_srcdir}/common
> 
> libauparse_la_SOURCES = lru.c interpret.c nvlist.c ellist.c   \
>   auparse.c auditd-config.c message.c data_buf.c  \
>   auparse-defs.h  auparse-idata.h data_buf.h  \
>   nvlist.h auparse.h ellist.h \
>   internal.h lru.h rnode.h interpret.h\
>   private.h expression.c expression.h tty_named_keys.h\
>   normalize.c normalize-llist.c normalize-llist.h \
>   normalize-internal.h normalize_obj_kind_map.h   \
>   normalize_record_map.h normalize_syscall_map.h
> 
> We can find following line in internal.h
> 
> #include "auditd-config.h"
> 
> I can find src/auditd-config.h file which is GPLv2.
> 
> The "src/auditd-config.h" should be also LGPLv2.1

That file is also mislabeled. It is now corrected. Thanks for the review.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [RFC PATCH v9 07/16] uapi|audit|ipe: add ipe auditing support

[Steve Grubb]

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 respect to IPE
> itself.
> 
> The new 1420 audit, AUDIT_IPE_ACCESS indicates the result of a policy
> evaulation of a resource. The other two events, AUDIT_MAC_POLICY_LOAD,
> and AUDIT_MAC_CONFIG_CHANGE represent a new policy was loaded into the
> kernel and the currently active policy changed, respectively.

Typically when you reuse an existing record type, it is expected to maintain 
the same fields in the same order. Also, it is expect that fields that are 
common across diferent records have the same meaning. To aid in this, we have 
a field dictionary here:

https://github.com/linux-audit/audit-documentation/blob/main/specs/fields/
field-dictionary.csv

For example, dev is expected to be 2 hex numbers separated by a colon which 
are the device major and minor numbers. But down a couple lines from here, we 
find dev="tmpfs". But isn't that a filesystem type?

> This patch also adds support for success auditing, allowing users to
> identify how a resource passed policy. It is recommended to use this
> option with caution, as it is quite noisy.
> 
> This patch adds the following audit records:
> 
>   audit: AUDIT1420 path="/tmp/tmpwxmam366/deny/bin/hello" dev="tmpfs"
> ino=72 rule="DEFAULT op=EXECUTE action=DENY"

Do we really need to log the whole rule?

>   The above audit record shows IPE blocked a file
> /tmp/tmpwxmam366/deny/bin/hello in the temp file system.
> 
>   audit: AUDIT1420 path="/tmp/tmpxkvb3d9x/deny/bin/hello" dev="tmpfs"
> ino=157 rule="DEFAULT action=DENY"
> 
>   The above audit record shows IPE blocked a file
> /tmp/tmpxkvb3d9x/deny/bin/hello in the temp file system via another
> rule.
> 
>   audit: MAC_POLICY_LOAD policy_name="dmverity_roothash"
> policy_version=0.0.0 sha256=DC67AC19E05894EFB3170A8E55DE529794E248C2
> auid=4294967295 ses=4294967295 lsm=ipe res=1

The MAC_POLICY_LOAD record type simply states the lsm that had it's policy 
loaded. There isn't name, version, and hash information. I'd prefer to see 
all users of this record type decide if it should be extended because they 
also have that information available to record.

>   The above audit record shows IPE loaded a new policy named
> "dmverity_roothash" with the sha256 hash of the policy.
> 
>   audit: MAC_CONFIG_CHANGE old_active_pol_name="Allow_All"
> old_active_pol_version=0.0.0
> old_sha256=DA39A3EE5E6B4B0D3255BFEF95601890AFD80709
> new_active_pol_name="dmverity_roothash" new_active_pol_version=0.0.0
> new_sha256=DC67AC19E05894EFB3170A8E55DE529794E248C2
> auid=4294967295 ses=4294967295 lsm=ipe res=1
> 
>   The above audit record shows IPE's active policy switched from
> "Allow_All" to "dmverity_roothash".

Shouldn't this just be another MAC_POLICY_LOAD? That would match other LSM's. 
The MAC_CONFIG_CHANGE is to denote that a changeable option was modified from 
one value to another. But it is still operating under the same policy.

-Steve

> These result in the following events (the audit records are always
> prior to a SYSCALL record):
> 
>   audit: AUDIT1420 path="/tmp/tmpwxmam366/deny/bin/hello" dev="tmpfs"
> ino=72 rule="DEFAULT op=EXECUTE action=DENY"
>   audit[476]: SYSCALL arch=c03e syscall=59 success=no exit=-13
> a0=7f7d01b5e890 a1=7f7d01f80e80 a2=7ffde535f230 a3=0 items=0 ppid=229
> pid=476 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=pts0 ses=4294967295 comm="python3" exe="/usr/bin/python3.10"
> key=(null)
>   audit: PROCTITLE
> proctitle=707974686F6E3300746573742F6D61696E2E7079002D66002E2E
> 
>   The above events shows IPE blocked the hello file which python was
> trying to execute.
> 
>   audit: AUDIT1420 path="/tmp/tmpxkvb3d9x/deny/bin/hello" dev="tmpfs"
> ino=157 rule="DEFAULT action=DENY"
>   audit[1195]: SYSCALL arch=c03e syscall=9 success=no
> exit=-13 a0=0 a1=18020 a2=6 a3=2 items=0 ppid=997 pid=1195
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=pts0 ses=4294967295 comm="mmap_test"
> exe="/tmp/ipe-test/bin/mmap_test" key=(null)
>   audit: PROCTITLE
> proctitle=2F746D702F6970652D746573742F62696E2F6D6D61705F746573
> 
>   The above events shows IPE blocked the hello file which
> /tmp/ipe-test/bin/mmap_test was trying to mmap.
> 
>   audit: MAC_POLICY_LOAD policy_name="dmverity_roothash"
> policy_version=0.0.0 sha256=DC67AC19E05894EFB3170A8E55DE529794E248C2
> auid=4294967295 ses=4294967295 lsm=ipe res=1
>   audit[229]: SYSCALL arch=c03e syscall=1 success=yes exit=2567 a0=3
> a1=5596fcae1fb0 a2=a07 a3=2 items=0 ppid=184 pid=229 auid=4294967295
> uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sg
> id=0 fsgid=0 tty=pts0 

Re: audit library license

[Steve Grubb]

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 under LGPL so that it may be
> linked with 3rd party software.
> 
> I found that latest audit library linked libaucommon.so.
> 
> ./lib/Makefile.in:AM_CPPFLAGS = -I. -I${top_srcdir} -I${top_srcdir}/auparse
> -I${top_srcdir}/common ./lib/Makefile.in:libaudit_la_LIBADD =
> $(CAPNG_LDADD) ${top_builddir}/common/libaucommon.la
> ./lib/Makefile.in:libaudit_la_DEPENDENCIES = $(libaudit_la_SOURCES)
> ../config.h ${top_builddir}/common/libaucommon.la
> 
> ./auparse/Makefile.am:AM_CPPFLAGS = -I. -I${top_srcdir} -I${top_srcdir}/src
> -I${top_srcdir}/lib -I${top_srcdir}/common
> ./auparse/Makefile.am:libauparse_la_LIBADD =
> ${top_builddir}/lib/libaudit.la ${top_builddir}/common/libaucommon.la
> ./auparse/Makefile.am:libauparse_la_DEPENDENCIES =
> $(libauparse_la_SOURCES) ${top_builddir}/config.h
> ${top_builddir}/common/libaucommon.la
> 
> Libaucommo.so is created by following files
> 
> ./common/Makefile.am:libaucommon_la_SOURCES = audit-fgets.c strsplit.c
> 
> And the license of audit/common/audit-fgets.c is GPLv2
> 
> This mean the license of latest audit libraries are also GPLv2.
> 
> Is my understanding correct?

The intention stated in the README file is correct. The code in question is 
only used by 3 plugins which are GPL and those functions are hidden from 
external users of libaudit. The code can be relicenced to make it LGPL so 
everything matches the intentions.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Setting priority to auditd rule files

[Steve Grubb]

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 "ls -v".

> Is there a way to force auditd to prioritize which rule file should be
> first read and applied, other than renaming it as 000-.rules and
> hoping that customers don't have anything lexicographically smaller than
> this?

You can use "ls -v" to figure out how to make a rule that is ahead of 10-base-
config.rules. even 10-a.rule should go first. Or you can rename 10-base-
config.rules to be a higher number.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v1 2/2] io_uring,audit: do not log IORING_OP_*GETXATTR

[Steve Grubb]

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: add fgetxattr and getxattr support")
> > Signed-off-by: Richard Guy Briggs 
> > ---
> > io_uring/opdef.c | 2 ++
> > 1 file changed, 2 insertions(+)
> 
> Depending on your security policy, fetching file data, including
> xattrs, can be interesting from a security perspective.  As an
> example, look at the SELinux file/getattr permission.
> 
> https://github.com/SELinuxProject/selinux-notebook/blob/main/src/object_cla
> sses_permissions.md#common-file-permissions

We're mostly interested in setting attributes because that changes policy. 
Reading them is not interesting unless the access fails with EPERM.

I was updating the user space piece recently and saw there was a bunch of 
"new" operations. I was commenting that we need to audit 5 or 6 of the "new" 
operations such as IORING_OP_MKDIRATor IORING_OP_SETXATTR. But now that I see 
the patch, it looks like they are auditable and we can just let a couple be 
skipped. IORING_OP_MADVISE is not interesting as it just gives hiints about 
the expected access patterns of memory. If there were an equivalent of 
mprotect, that would be of interest, but not madvise.

There are some I'm not sure about such as IORING_OP_MSG_RING and 
IORING_OP_URING_CMD. What do they do?

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v1 1/2] io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE

[Steve Grubb]

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,
> > >> 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
> > >> 
> > >> ---
> > >> 
> > >>  io_uring/opdef.c | 2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >> 
> > >> diff --git a/io_uring/opdef.c b/io_uring/opdef.c
> > >> index 3aa0d65c50e3..a2bf53b4a38a 100644
> > >> --- a/io_uring/opdef.c
> > >> +++ b/io_uring/opdef.c
> > >> @@ -306,12 +306,12 @@ const struct io_op_def io_op_defs[] = {
> > >> 
> > >> },
> > >> [IORING_OP_FADVISE] = {
> > >> 
> > >> .needs_file = 1,
> > >> 
> > >> -   .audit_skip = 1,
> > >> 
> > >> .name   = "FADVISE",
> > >> .prep   = io_fadvise_prep,
> > >> .issue  = io_fadvise,
> > >> 
> > >> },
> > > 
> > > I've never used posix_fadvise() or the associated fadvise64*()
> > > syscalls, but from quickly reading the manpages and the
> > > generic_fadvise() function in the kernel I'm missing where the fadvise
> > > family of functions could be used to truncate a file, can you show me
> > > where this happens?  The closest I can see is the manipulation of the
> > > page cache, but that shouldn't actually modify the file ... right?
> > 
> > Yeah, honestly not sure where that came from. Maybe it's being mixed up
> > with fallocate?
> 
> That was my thought too when I was looking at it.

Oh. Yeah. fallocate is the one that truncates. fadvise can be skipped.

-Steve

> > All fadvise (or madvise, for that matter) does is
> > provide hints on the caching or access pattern. On second thought, both
> > of these should be able to set audit_skip as far as I can tell.
> 
> Agreed on the fadvise side, and probably the madvise side too,
> although the latter has more options/code to sift through so I'm
> curious to hear what analysis Richard has done on that one.




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v1 0/2] two suggested iouring op audit updates

[Steve Grubb]

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  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 audit bypass selections
> > >>>>> suggested in consultation with Steve Grubb.
> > >>>>> 
> > >>>>> Richard Guy Briggs (2):
> > >>>>>   io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE
> > >>>>>   io_uring,audit: do not log IORING_OP_*GETXATTR
> > >>>>>  
> > >>>>>  io_uring/opdef.c | 4 +++-
> > >>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
> > >>>> 
> > >>>> Look fine to me - we should probably add stable to both of them,
> > >>>> just to keep things consistent across releases. I can queue them up
> > >>>> for 6.3.
> > >>> 
> > >>> Please hold off until I've had a chance to look them over ...
> > >> 
> > >> I haven't taken anything yet, for things like this I always let it
> > >> simmer until people have had a chance to do so.
> > > 
> > > Thanks.  FWIW, that sounds very reasonable to me, but I've seen lots
> > > of different behaviors across subsystems and wanted to make sure we
> > > were on the same page.
> > 
> > Sounds fair. BTW, can we stop CC'ing closed lists on patch
> > submissions? Getting these:
> > 
> > Your message to Linux-audit awaits moderator approval
> > 
> > on every reply is really annoying.
> 
> We kinda need audit related stuff on the linux-audit list, that's our
> mailing list for audit stuff.
> 
> However, I agree that it is crap that the linux-audit list is
> moderated, but unfortunately that isn't something I control (I haven't
> worked for RH in years, and even then the list owner was really weird
> about managing the list).  Occasionally I grumble about moving the
> kernel audit development to a linux-audit list on vger but haven't
> bothered yet, perhaps this is as good a reason as any.
> 
> Richard, Steve - any chance of opening the linux-audit list?

Unfortunately, it really has to be this way. I deleted 10 spam emails 
yesterday. It seems like some people subscribed to this list are compromised. 
Because everytime there is a legit email, it's followed in a few seconds by a 
spam email.

Anyways, all legit email will be approved without needing to be subscribed.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v6 3/3] fanotify, audit: Allow audit to use the full permission event response

[Steve Grubb]

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,
> > > > 
> > > > 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 better to just make it 0?
> > > 
> > > ...
> > > 
> > > > On Tuesday, January 17, 2023 4:14:07 PM EST Richard Guy Briggs wrote:
> > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > > index d1fb821de104..3133c4175c15 100644
> > > > > --- a/kernel/auditsc.c
> > > > > +++ b/kernel/auditsc.c
> > > > > @@ -2877,10 +2878,19 @@ void __audit_log_kern_module(char *name)
> > > > > 
> > > > >   context->type = AUDIT_KERN_MODULE;
> > > > >  
> > > > >  }
> > > > > 
> > > > > -void __audit_fanotify(u32 response)
> > > > > +void __audit_fanotify(u32 response, struct
> > > > > fanotify_response_info_audit_rule *friar) {
> > > > > - audit_log(audit_context(), GFP_KERNEL,
> > > > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > > > + /* {subj,obj}_trust values are {0,1,2}: no,yes,unknown */
> > > > > + if (friar->hdr.type == FAN_RESPONSE_INFO_NONE) {
> > > > > + audit_log(audit_context(), GFP_KERNEL,
> > > > > AUDIT_FANOTIFY,
> > > > > +   "resp=%u fan_type=%u fan_info=3F
> > > > > subj_trust=2
> > > > 
> > > > obj_trust=2",
> > > > 
> > > > > +   response, FAN_RESPONSE_INFO_NONE);
> > > > > + return;
> > > > > + }
> > > 
> > > (I'm working under the assumption that the "fan_info=3F" in the record
> > > above is what Steve was referring to in his comment.)
> > > 
> > > I vaguely recall Richard commenting on this in the past, although
> > > maybe not ... my thought is that the "3F" is simply the hex encoded
> > > "?" character in ASCII ('man 7 ascii' is your friend).  I suppose the
> > > question is what to do in the FAN_RESPONSE_INFO_NONE case.
> > > 
> > > Historically when we had a missing field we would follow the "field=?"
> > > pattern, but I don't recall doing that for a field which was
> > > potentially hex encoded, is there an existing case where we use "?"
> > > for a field that is hex encoded?  If so, we can swap out the "3F" for
> > > a more obvious "?".
> > 
> > I was presuming encoding the zero: "30"
> 
> I'm sorry, but you've lost me here.
> 
> > > However, another option might be to simply output the current
> > > AUDIT_FANOTIFY record format in the FAN_RESPONSE_INFO_NONE case, e.g.
> > > only "resp=%u".  This is a little against the usual guidance of
> > > "fields should not disappear from a record", but considering that
> > > userspace will always need to support the original resp-only format
> > > for compatibility reasons this may be an option.
> > 
> > I don't have a strong opinion.
> 
> I'm not sure I care too much either.  I will admit that the "3F" seems
> to be bordering on the "bit too clever" side of things, but it's easy
> to argue it is in keeping with the general idea of using "?" to denote
> absent/unknown fields.

The translation will be from %X to %u. In that case, someone might think 63 
has some meaning. It would be better to leave it as 0 so there's less to 
explain.

-Steve

> As Steve was the one who raised the question in this latest round, and
> he knows his userspace tools the best, it seems wise to get his input
> on this.




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v6 3/3] fanotify, audit: Allow audit to use the full permission event response

[Steve Grubb]

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 better to 
just make it 0?  Btw, the change to %X makes life easier. Thx.

-Steve


On Tuesday, January 17, 2023 4:14:07 PM EST Richard Guy Briggs wrote:
> This patch passes the full response so that the audit function can use all
> of it. The audit function was updated to log the additional information in
> the AUDIT_FANOTIFY record.
> 
> 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.
> 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(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/r/3075502.aeNJFYEL58@x2
> Signed-off-by: Richard Guy Briggs 
> ---
>  fs/notify/fanotify/fanotify.c |  3 ++-
>  include/linux/audit.h |  9 +
>  kernel/auditsc.c  | 16 +---
>  3 files changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 24ec1d66d5a8..29bdd99b29fa 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -273,7 +273,8 @@ static int fanotify_get_response(struct fsnotify_group
> *group,
> 
>   /* Check if the response should be audited */
>   if (event->response & FAN_AUDIT)
> - audit_fanotify(event->response & ~FAN_AUDIT);
> + audit_fanotify(event->response & ~FAN_AUDIT,
> +>audit_rule);
> 
>   pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__,
>group, event, ret);
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index d6b7d0c7ce43..31086a72e32a 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #define AUDIT_INO_UNSET ((unsigned long)-1)
>  #define AUDIT_DEV_UNSET ((dev_t)-1)
> @@ -416,7 +417,7 @@ extern void __audit_log_capset(const struct cred *new,
> const struct cred *old); extern void __audit_mmap_fd(int fd, int flags);
>  extern void __audit_openat2_how(struct open_how *how);
>  extern void __audit_log_kern_module(char *name);
> -extern void __audit_fanotify(u32 response);
> +extern void __audit_fanotify(u32 response, struct
> fanotify_response_info_audit_rule *friar); extern void
> __audit_tk_injoffset(struct timespec64 offset);
>  extern void __audit_ntp_log(const struct audit_ntp_data *ad);
>  extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int
> nentries, @@ -523,10 +524,10 @@ static inline void
> audit_log_kern_module(char *name) __audit_log_kern_module(name);
>  }
> 
> -static inline void audit_fanotify(u32 response)
> +static inline void audit_fanotify(u32 response, struct
> fanotify_response_info_audit_rule *friar) {
>   if (!audit_dummy_context())
> - __audit_fanotify(response);
> + __audit_fanotify(response, friar);
>  }
> 
>  static inline void audit_tk_injoffset(struct timespec64 offset)
> @@ -679,7 +680,7 @@ static inline void audit_log_kern_module(char *name)
>  {
>  }
> 
> -static inline void audit_fanotify(u32 response)
> +static inline void audit_fanotify(u32 response, struct
> fanotify_response_info_audit_rule *friar) { }
> 
>  static inline void audit_tk_injoffset(struct timespec64 offset)
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index d1fb821de104..3133c4175c15 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -64,6 +64,7 @@
>  #include 
>  #include 
>  #include  // struct open_how
> +#include 
> 
>  #include "audit.h"
> 
> @@ -2877,10 +2878,19 @@ void __audit_log_kern_module(char *name)
>   context->type = AUDIT_KERN_MODULE;
>  }
> 
> -void __audit_fanotify(u32 response)
> +void __audit_fanotify(u32 response, struct
> fanotify_response_info_audit_rule *friar) {
> - audit_log(audit_context(), GFP_KERNEL,
> - AUDIT_FANOTIFY, "resp=%u", response);
> + /* {subj,obj}_trust values are {0,1,2}: no,yes,unknown */
> + if (friar->hdr.type == FAN_RESPONSE_INFO_NONE) {
> + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> 

Re: Difference between BITMAP_EXECUTABLE_PATH and BITMAP_EXCLUDE_EXTEND flags

[Steve Grubb]

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://listman.redhat.com/archives/linux-audit/2015-August/010585.html

> AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND

This ^^^ means that the exclude filter supports many more kinds of fields than 
the original design allowed for. 
https://listman.redhat.com/archives/linux-audit/2016-June/011433.html

For upstream kernels and ones derived after it was release, the second 
implies the first one is already included.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v5 3/3] fanotify, audit: Allow audit to use the full permission event response

[Steve Grubb]

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, , sizeof(struct fanotify_response));
> > 
> > I get access denials. Every time. If the program is using the new API and
> > sets FAN_INFO, then it works as expected. I'll do some more testing but I
> > think there is something wrong in the compatibility path.
> 
> I'll have a closer look, because this wasn't the intended behaviour.

I have done more testing. I think what I saw might have been caused by a 
stale selinux label (label exists, policy is deleted). With selinux in 
permissive mode it's all working as expected - both old and new API.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Identify whether the kernel version supports Path based exclusion

[Steve Grubb]

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_add_rule_data to add a temporary path
> based rule and check if it is successful, but this won't work when auditd
> is running in immutable mode.
> 
> Any other way which does not require checking versions of Kernel or
> Distribution?

If you are looking to see if this is supported

-a always,exclude  -F exec=/usr/bin/ls

then it can be detected by:

uint32_t features = audit_get_features();
if ((features & AUDIT_FEATURE_BITMAP_EXCLUDE_EXTEND) == 0)
puts("not supported");
else
puts("supported");

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v5 3/3] fanotify, audit: Allow audit to use the full permission event response

[Steve Grubb]

Hello,

Sorry to take so long. Holidays and kernel build problems. However, I have 
built a kernel with these patches. I only have 2 comments. 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, , sizeof(struct fanotify_response));

I get access denials. Every time. If the program is using the new API and 
sets FAN_INFO, then it works as expected. I'll do some more testing but I 
think there is something wrong in the compatibility path.

On Monday, December 12, 2022 9:06:11 AM EST Richard Guy Briggs wrote:
> This patch passes the full response so that the audit function can use all
> of it. The audit function was updated to log the additional information in
> the AUDIT_FANOTIFY record.

What I'm seeing is:

type=FANOTIFY msg=audit(01/09/2023 18:43:16.306:366) : resp=deny fan_type=1 
fan_info=3133 subj_trust=0 obj_trust=0

Where fan_info was supposed to be 13 decimal. More below...

> 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.
> Hex encoding suggested by Paul Moore .
> 
> Sample 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/r/3075502.aeNJFYEL58@x2
> Signed-off-by: Richard Guy Briggs 
> ---
>  fs/notify/fanotify/fanotify.c |  3 ++-
>  include/linux/audit.h |  9 +
>  kernel/auditsc.c  | 25 ++---
>  3 files changed, 29 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 24ec1d66d5a8..29bdd99b29fa 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -273,7 +273,8 @@ static int fanotify_get_response(struct fsnotify_group
> *group,
> 
>   /* Check if the response should be audited */
>   if (event->response & FAN_AUDIT)
> - audit_fanotify(event->response & ~FAN_AUDIT);
> + audit_fanotify(event->response & ~FAN_AUDIT,
> +>audit_rule);
> 
>   pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__,
>group, event, ret);
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index d6b7d0c7ce43..31086a72e32a 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #define AUDIT_INO_UNSET ((unsigned long)-1)
>  #define AUDIT_DEV_UNSET ((dev_t)-1)
> @@ -416,7 +417,7 @@ extern void __audit_log_capset(const struct cred *new,
> const struct cred *old); extern void __audit_mmap_fd(int fd, int flags);
>  extern void __audit_openat2_how(struct open_how *how);
>  extern void __audit_log_kern_module(char *name);
> -extern void __audit_fanotify(u32 response);
> +extern void __audit_fanotify(u32 response, struct
> fanotify_response_info_audit_rule *friar); extern void
> __audit_tk_injoffset(struct timespec64 offset);
>  extern void __audit_ntp_log(const struct audit_ntp_data *ad);
>  extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int
> nentries, @@ -523,10 +524,10 @@ static inline void
> audit_log_kern_module(char *name) __audit_log_kern_module(name);
>  }
> 
> -static inline void audit_fanotify(u32 response)
> +static inline void audit_fanotify(u32 response, struct
> fanotify_response_info_audit_rule *friar) {
>   if (!audit_dummy_context())
> - __audit_fanotify(response);
> + __audit_fanotify(response, friar);
>  }
> 
>  static inline void audit_tk_injoffset(struct timespec64 offset)
> @@ -679,7 +680,7 @@ static inline void audit_log_kern_module(char *name)
>  {
>  }
> 
> -static inline void audit_fanotify(u32 response)
> +static inline void audit_fanotify(u32 response, struct
> fanotify_response_info_audit_rule *friar) { }
> 
>  static inline void audit_tk_injoffset(struct timespec64 offset)
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index d1fb821de104..8d523066d81f 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -64,6 +64,7 @@
>  #include 
>  #include 
>  #include  // struct open_how
> +#include 
> 
>  #include "audit.h"
> 
> @@ -2877,10 +2878,28 @@ void __audit_log_kern_module(char *name)
>   context->type = AUDIT_KERN_MODULE;
>  }
> 
> -void __audit_fanotify(u32 response)
> +void __a

Re: A question on monitoring time or time management changes in the kernel and the adjtimex system call

[Steve Grubb]

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 the event?

I think if you see either, time has been changed. I haven't studied the 
syscall to see if there isn't a sneak path, but I think they can be relied 
on.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: New bug in Audit

[Steve Grubb]

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 my response) as upstream isn't really going to be able
> > to provide adequate help for someone experiencing problems with a
> > distro kernel which has a number of patches and backports.
> > 
> > If you have a problem with this approach, perhaps we should move
> > upstream development to an audit mailing list on vger.kernel.org and
> > leave this list for RH specific issues?
> 
> Steve, I realize it's only been ~24hrs, but should I assume you are
> okay with that (the upstream focused approach)?

For the 18 years I've spent on this mail list, it has alway been open to any 
topic audit related. I've answered questions for many distributions. If I can 
reproduce the issue, then it's a bug worth looking at. If I can't reproduce 
it, I let them know. I've even answered questions for people writing their 
own audit implementation.

A lot of the email is upstream kernel work - no doubt. But Many times, we 
miss upstream kernel bugs because no one is running upstream code. We usually 
hear about it when a distribution which stays close to upstream releases a 
new update.

The text where you sign up for this mail list does not limit the topc to 
upstream work, it allows for any discussion as long as it's audit related. I 
do not think making a new mail list is in anyone's interest. Bugs will always 
get misreported if there are 2 lists.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: New bug in Audit

[Steve Grubb]

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
> 
> This mailing list is focused on the development and support of
> upstream Linux Kernels and Steve's audit userspace, we don't really
> provide support for paid distributions.  If you are seeing problems
> with the upstream Linux Kernel or tools, please report them here, but
> issues with distribution kernels and/or tools should be sent to the
> distribution for support/assistance.

Paul, we take bug reports and help requests from anyone. Often, distributions 
are how we first hear of problems.

> I believe you should be able to submit a bug report against Red Hat
> Enterprise Linux using the Red Hat bugzilla instance at the URL below:

I believe this is fixed by this commit:

https://github.com/linux-audit/audit-kernel/commit/
1b2263a807ca651f94517b1b22dc5f13e494984d

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: BPF audit logs

[Steve Grubb]

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=audit(21/12/22 09:04:05.883:460) : prog-id=0 op=UNLOAD
> I also note that the bpf auxillary structure (struct bpf_prog_aux) that
> holds the program id value, also holds a name (struct bpf_prog_aux->name)
> and uid  (struct bpf_prog_aud->user_struct->uid). Perhaps adding these two
> items to the AUDIT_BPF event would provide more security context for this
> unsolicited event. Thoughts?

I agree that the resulting event leaves a lot to be desired. When the patch 
was being merged, I think it was pointed out that all we have is a number. 
The BPF folks seemed to insist that was all that was needed. They never 
explained how to use that number for anything practical like knowing what was 
loaded. If anything can be done to improve the situation, I'd like to 
encourage a patch. Systemd triggers a bunch of these events. But what it's 
doing is unknowable.

-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH 1/3] audit: cache ctx->major in audit_filter_syscall()

[Steve Grubb]

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 would suggest 
adding some comment in the code that this is for a performance improvement 
and to see the commit message for additional info.

Thanks,
-Steve

On Tuesday, September 27, 2022 6:59:42 PM EDT Ankur Arora wrote:
> ctx->major contains the current syscall number. This is, of course, a
> constant for the duration of the syscall. Unfortunately, GCC's alias
> analysis cannot prove that it is not modified via a pointer in the
> audit_filter_syscall() loop, and so always loads it from memory.
> 
> In and of itself the load isn't very expensive (ops dependent on the
> ctx->major load are only used to determine the direction of control flow
> and have short dependence chains and, in any case the related branches
> get predicted perfectly in the fastpath) but still cache ctx->major
> in a local for two reasons:
> 
> * ctx->major is in the first cacheline of struct audit_context and has
>   similar alignment as audit_entry::list audit_entry. For cases
>   with a lot of audit rules, doing this reduces one source of contention
>   from a potentially busy cache-set.
> 
> * audit_in_mask() (called in the hot loop in audit_filter_syscall())
>   does cast manipulation and error checking on ctx->major:
> 
>  audit_in_mask(const struct audit_krule *rule, unsigned long val):
>  if (val > 0x)
>  return false;
> 
>  word = AUDIT_WORD(val);
>  if (word >= AUDIT_BITMASK_SIZE)
>  return false;
> 
>  bit = AUDIT_BIT(val);
> 
>  return rule->mask[word] & bit;
> 
>   The clauses related to the rule need to be evaluated in the loop, but
>   the rest is unnecessarily re-evaluated for every loop iteration.
>   (Note, however, that most of these are cheap ALU ops and the branches
>are perfectly predicted. However, see discussion on cycles
>improvement below for more on why it is still worth hoisting.)
> 
> On a Skylakex system change in getpid() latency (aggregated over
> 12 boot cycles):
> 
>  Min Mean  Median Max   pstdev
> (ns) (ns)(ns)(ns)
> 
>  -201.30   216.14  216.22  228.46  (+- 1.45%)
>  +196.63   207.86  206.60  230.98  (+- 3.92%)
> 
> Performance counter stats for 'bin/getpid' (3 runs) go from:
> cycles   836.89  (  +-   .80% )
> instructions2000.19  (  +-   .03% )
> IPC2.39  (  +-   .83% )
> branches 430.14  (  +-   .03% )
> branch-misses  1.48  (  +-  3.37% )
> L1-dcache-loads  471.11  (  +-   .05% )
> L1-dcache-load-misses  7.62  (  +- 46.98% )
> 
>  to:
> cycles   805.58  (  +-  4.11% )
> instructions1654.11  (  +-   .05% )
> IPC2.06  (  +-  3.39% )
> branches 430.02  (  +-   .05% )
> branch-misses  1.55  (  +-  7.09% )
> L1-dcache-loads  440.01  (  +-   .09% )
> L1-dcache-load-misses  9.05  (  +- 74.03% )
> 
> (Both aggregated over 12 boot cycles.)
> 
> instructions: we reduce around 8 instructions/iteration because some of
> the computation is now hoisted out of the loop (branch count does not
> change because GCC, for reasons unclear, only hoists the computations
> while keeping the basic-blocks.)
> 
> cycles: improve by about 5% (in aggregate and looking at individual run
> numbers.) This is likely because we now waste fewer pipeline resources
> on unnecessary instructions which allows the control flow to
> speculatively execute further ahead shortening the execution of the loop
> a little. The final gating factor on the performance of this loop
> remains the long dependence chain due to the linked-list load.
> 
> Signed-off-by: Ankur Arora 
> ---
>  kernel/auditsc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 79a5da1bc5bb..533b087c3c02 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -843,13 +843,14 @@ static void audit_filter_syscall(struct task_struct
> *tsk, {
>   struct audit_entry *e;
>   enum audit_state state;
> + unsigned long major = ctx->major;
> 
>   if (auditd_test_task(tsk))
>   return;
> 
>   rcu_read_lock();
>   list_for_each_entry_rcu(e, _filter_list[AUDIT_FILTER_EXIT], 
list) {
> - if (audit_in_mask(>rule, ctx->major) &&
> + if (audit_in_mask(>rule, major) &&
>   audit_filter_rules(tsk, >rule, ctx, NULL,
>  , false)) {
>   rcu_read_unlock();




--
Linux-audit mailing list
Linux-audit@redhat.com

Re: Query regarding the lib audit-userspace

[Steve Grubb]

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 audit
> subsystem. 

audit_log_acct_message()  is meant to send events related to a user's 
account. For example, pam and shadow-utils uses it.

> From the man pages I understand that every message to the
> kernel audit subsystem would get an ACK back.

Yes. This is to let you know if there was a problem such as lack of 
permissions.

> Now my question is does the daemon[single threaded] consuming this libaudit
> for sending events using audit_log_acct_message() API be blocked until it
> gets an ACK back from the kernel ?

Yes. In general, sending audit events should be rare.

> If yes , is there a way to not have the application blocked during this
> period ?

The requirements that we normally need to adhere to is that if the audit 
event fails, then whatever the user was going to do needs to be prevented. If 
you really need to keep moving, send the event on it's own thread so that 
your application is not waiting. For example, sshd forks the user session so 
that it can keep processing other logins. But on that fork, it waits for the 
responses to make it easier to tear down the session if sending an audit 
event fails.

Or, another approach would be to write the whole thing down to calling sendto 
and then you can wait however you want. I think putting on it's own thread is 
simplest. But as I said in the beginning, should there be a problem logging 
the event, can you undo whatever the event was for if you keep going?

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response

[Steve Grubb]

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.
>
> Or "trust" with sub-fields "subj" and "obj"?

No. just make them separate and u32. subj_trust and obj_trust - no sub fields. 
If we have sub-fields, that probably means bit mapping and that wasn't wanted.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response

[Steve Grubb]

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 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
> > > > a decision was made because the file was untrusted or access denied
> > > > for
> > > > another reason.
> > > 
> > > So, "u32 trusted;" ?  How would you like that formatted?
> > > "fan_trust={0|1}"
> > 
> > So how does this play out if there is another user? Do they want a num=
> > and trust=  if not, then the AUDIT_FANOTIFY record will have multiple
> > formats which is not good. I'd rather suggest something generic that can
> > be interpreted based on who's attached to fanotify. IOW we have a
> > fan_type=0 and then followed by info0= info1=  the interpretation of
> > those solely depend on fan_type. If the fan_type does not need both,
> > then any interpretation skips what it doesn't need. If fan_type=1, then
> > it follows what arg0= and arg1= is for that format. But make this pivot
> > on fan_type and not actual names.
> So I think there is some misunderstanding so let me maybe spell out in
> detail how I see things so that we can get on the same page:
> 
> It was a requirement from me (and probably Amir) that there is a generic
> way to attach additional info to a response to fanotify permission event.
> This is achieved by defining:
> 
> struct fanotify_response_info_header {
>__u8 type;
>__u8 pad;
>__u16 len;
> };
> 
> which is a generic header and kernel can based on 'len' field decide how
> large the response structure is (to safely copy it from userspace) and
> based on 'type' field it can decide who should be the recipient of this
> extra information (or generally what to do with it). So any additional
> info needs to start with this header.
> 
> Then there is:
> 
> struct fanotify_response_info_audit_rule {
>struct fanotify_response_info_header hdr;
>__u32 audit_rule;
> };
> 
> which properly starts with the header and hdr.type is expected to be
> FAN_RESPONSE_INFO_AUDIT_RULE. What happens after the header with type
> FAN_RESPONSE_INFO_AUDIT_RULE until length hdr.len is fully within *audit*
> subsystem's responsibility. Fanotify code will just pass this as an opaque
> blob to the audit subsystem.
> 
> So if you know audit subsystem will also need some other field together
> with 'audit_rule' now is a good time to add it and it doesn't have to be
> useful for anybody else besides audit. If someone else will need other
> information passed along with the response, he will append structure with
> another header with different 'type' field. In principle, there can be
> multiple structures appended to fanotify response like
> 
> ...
> 
> and fanotify subsystem will just pass them to different receivers based
> on the type in 'hdr' field.
> 
> Also if audit needs to pass even more information along with the respose,
> we can define a new 'type' for it. But the 'type' space is not infinite so
> I'd prefer this does not happen too often...
> 
> I hope this clears out things a bit.

Yes. Thank you.

Richard,  add subj_trust and obj_trust. These can be 0|1|2 for no, yes, 
unknown.

-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response

[Steve Grubb]

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
> > a decision was made because the file was untrusted or access denied for
> > another reason.
>
> So, "u32 trusted;" ?  How would you like that formatted?
> "fan_trust={0|1}"

So how does this play out if there is another user? Do they want a num= and 
trust=  if not, then the AUDIT_FANOTIFY record will have multiple formats 
which is not good. I'd rather suggest something generic that can be 
interpreted based on who's attached to fanotify. IOW we have a fan_type=0 and 
then followed by info0= info1=  the interpretation of those solely depend on 
fan_type. If the fan_type does not need both, then any interpretation skips 
what it doesn't need. If fan_type=1, then it follows what arg0= and arg1= is 
for that format. But make this pivot on fan_type and not actual names.
 
> > > You mention that you know what you want to put in the struct, why not
> > > share the details with all of us so we are all on the same page and
> > > can have a proper discussion.
> > 
> > Because I want to abide by the original agreement and not impose
> > opinionated requirements that serve no one else. I'd rather have
> > something anyone can use. I want to play nice.
> 
> If someone else wants to use something, why not give them a type of
> their own other than FAN_RESPONSE_INFO_AUDIT_RULE that they can shape
> however they like?

Please, let's keep AUDIT_FANOTIFY normalized but pivot on fan_type.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response

[Steve Grubb]

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, 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 that case, let's stick with leveraging the type/len fields in
> > > > > > the
> > > > > > fanotify_response_info_header struct, that should give us all the
> > > > > > flexibility we need.
> > > > > > 
> > > > > > Richard and Steve, it sounds like Steve is already aware of
> > > > > > additional
> > > > > > information that he wants to send via the
> > > > > > fanotify_response_info_audit_rule struct, please include that in
> > > > > > the
> > > > > > next revision of this patchset.  I don't want to get this merged
> > > > > > and
> > > > > > then soon after have to hack in additional info.
> > > > > 
> > > > > Steve, please define the type and name of this additional field.
> > > > 
> > > > Maybe extra_data, app_data, or extra_info. Something generic that can
> > > > be
> > > > reused by any application. Default to 0 if not present.
> > > 
> > > I think the point is being missed ... The idea is to not speculate on
> > > additional fields, as discussed we have ways to handle that, the issue
> > > was that Steve implied that he already had ideas for "things" he
> > > wanted to add.  If there are "things" that need to be added, let's do
> > > that now, however if there is just speculation that maybe someday we
> > > might need to add something else we can leave that until later.
> > 
> > This is not speculation. I know what I want to put there. I know you want
> > to pin it down to exactly what it is. However, when this started a
> > couple years back, one of the concerns was that we're building something
> > specific to 1 user of fanotify. And that it would be better for all
> > future users to have a generic facility that everyone could use if they
> > wanted to. That's why I'm suggesting something generic, its so this is
> > not special purpose that doesn't fit any other use case.
> 
> Well, we are talking specifically about fanotify in this thread and
> dealing with data structures that are specific to fanotify.  I can
> understand wanting to future proof things, but based on what we've
> seen in this thread I think we are all set in this regard.

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 a decision was 
made because the file was untrusted or access denied for another reason.

> You mention that you know what you want to put in the struct, why not
> share the details with all of us so we are all on the same page and
> can have a proper discussion.

Because I want to abide by the original agreement and not impose opinionated 
requirements that serve no one else. I'd rather have something anyone can 
use. I want to play nice.

-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response

[Steve Grubb]

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 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 that case, let's stick with leveraging the type/len fields in the
> > > > fanotify_response_info_header struct, that should give us all the
> > > > flexibility we need.
> > > > 
> > > > Richard and Steve, it sounds like Steve is already aware of
> > > > additional
> > > > information that he wants to send via the
> > > > fanotify_response_info_audit_rule struct, please include that in the
> > > > next revision of this patchset.  I don't want to get this merged and
> > > > then soon after have to hack in additional info.
> > > 
> > > Steve, please define the type and name of this additional field.
> > 
> > Maybe extra_data, app_data, or extra_info. Something generic that can be
> > reused by any application. Default to 0 if not present.
> 
> I think the point is being missed ... The idea is to not speculate on
> additional fields, as discussed we have ways to handle that, the issue
> was that Steve implied that he already had ideas for "things" he
> wanted to add.  If there are "things" that need to be added, let's do
> that now, however if there is just speculation that maybe someday we
> might need to add something else we can leave that until later.

This is not speculation. I know what I want to put there. I know you want to 
pin it down to exactly what it is. However, when this started a couple years 
back, one of the concerns was that we're building something specific to 1 user 
of fanotify. And that it would be better for all future users to have a 
generic facility that everyone could use if they wanted to. That's why I'm 
suggesting something generic, its so this is not special purpose that doesn't 
fit any other use case.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response

[Steve Grubb]

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 that case, let's stick with leveraging the type/len fields in the
> > fanotify_response_info_header struct, that should give us all the
> > flexibility we need.
> > 
> > Richard and Steve, it sounds like Steve is already aware of additional
> > information that he wants to send via the
> > fanotify_response_info_audit_rule struct, please include that in the
> > next revision of this patchset.  I don't want to get this merged and
> > then soon after have to hack in additional info.
> 
> Steve, please define the type and name of this additional field.

Maybe extra_data, app_data, or extra_info. Something generic that can be 
reused by any application. Default to 0 if not present.

Thanks,
-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response

[Steve Grubb]

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
> > > > > index 433418d73584..f000fec52360 100644
> > > > > --- a/kernel/auditsc.c
> > > > > +++ b/kernel/auditsc.c
> > > > > @@ -64,6 +64,7 @@
> > > > > #include 
> > > > > #include 
> > > > > #include  // struct open_how
> > > > > +#include 
> > > > > 
> > > > > #include "audit.h"
> > > > > 
> > > > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > > > context->type = AUDIT_KERN_MODULE;
> > > > > }
> > > > > 
> > > > > -void __audit_fanotify(u32 response)
> > > > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > > > {
> > > > > -   audit_log(audit_context(), GFP_KERNEL,
> > > > > -   AUDIT_FANOTIFY, "resp=%u", response);
> > > > > +   struct fanotify_response_info_audit_rule *friar;
> > > > > +   size_t c = len;
> > > > > +   char *ib = buf;
> > > > > +
> > > > > +   if (!(len && buf)) {
> > > > > +   audit_log(audit_context(), GFP_KERNEL,
> > > > > AUDIT_FANOTIFY,
> > > > > + "resp=%u fan_type=0 fan_info=?",
> > > > > response);
> > > > > +   return;
> > > > > +   }
> > > > > +   while (c >= sizeof(struct fanotify_response_info_header)) {
> > > > > +   friar = (struct fanotify_response_info_audit_rule
> > > > > *)buf;
> > > > 
> > > > Since the only use of this at the moment is the
> > > > fanotify_response_info_rule, why not pass the
> > > > fanotify_response_info_rule struct directly into this function?  We
> > > > can always change it if we need to in the future without affecting
> > > > userspace, and it would simplify the code.
> > > 
> > > Steve, would it make any sense for there to be more than one
> > > FAN_RESPONSE_INFO_AUDIT_RULE header in a message?  Could there be more
> > > than one rule that contributes to a notify reason?  If not, would it be
> > > reasonable to return -EINVAL if there is more than one?
> > 
> > I don't see a reason for sending more than one header. What is more
> > probable is the need to send additional data in that header. I was
> > thinking of maybe bit mapping it in the rule number. But I'd suggest
> > padding the struct just in case it needs expanding some day.
> 
> This doesn't exactly answer my question about multiple rules
> contributing to one decision.

I don't forsee that.
 
> The need for more as yet undefined information sounds like a good reason
> to define a new header if that happens.

It's much better to pad the struct so that the size doesn't change.

> At this point, is it reasonable to throw an error if more than one RULE
> header appears in a message?

It is a write syscall. I'd silently discard everything else and document that 
in the man pages. But the fanotify maintainers should really weigh in on 
this.

> The way I had coded this last patchset was to allow for more than one RULE
> header and each one would get its own record in the event.

I do not forsee a need for this.

> How many rules total are likely to exist?

Could be a thousand. But I already know some missing information we'd like to 
return to user space in an audit event, so the bit mapping on the rule number 
might happen. I'd suggest padding one u32 for future use.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response

[Steve Grubb]

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 
> > > #include  // struct open_how
> > > +#include 
> > > 
> > > #include "audit.h"
> > > 
> > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > context->type = AUDIT_KERN_MODULE;
> > > }
> > > 
> > > -void __audit_fanotify(u32 response)
> > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > {
> > > -   audit_log(audit_context(), GFP_KERNEL,
> > > -   AUDIT_FANOTIFY, "resp=%u", response);
> > > +   struct fanotify_response_info_audit_rule *friar;
> > > +   size_t c = len;
> > > +   char *ib = buf;
> > > +
> > > +   if (!(len && buf)) {
> > > +   audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > > + "resp=%u fan_type=0 fan_info=?", response);
> > > +   return;
> > > +   }
> > > +   while (c >= sizeof(struct fanotify_response_info_header)) {
> > > +   friar = (struct fanotify_response_info_audit_rule
> > > *)buf;
> > 
> > Since the only use of this at the moment is the
> > fanotify_response_info_rule, why not pass the
> > fanotify_response_info_rule struct directly into this function?  We
> > can always change it if we need to in the future without affecting
> > userspace, and it would simplify the code.
> 
> Steve, would it make any sense for there to be more than one
> FAN_RESPONSE_INFO_AUDIT_RULE header in a message?  Could there be more
> than one rule that contributes to a notify reason?  If not, would it be
> reasonable to return -EINVAL if there is more than one?

I don't see a reason for sending more than one header. What is more probable 
is the need to send additional data in that header. I was thinking of maybe 
bit mapping it in the rule number. But I'd suggest padding the struct just in 
case it needs expanding some day.

-Steev



--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

audit-3.0.9 released

[Steve Grubb]

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 non-zero
- Cleanup krb5 memory leaks on error paths
- Update auditd.cron to use auditctl --signal
- In auparse, if too many fields, realloc array bigger (Paul Wolneykien)
- In auparse, special case kernel module name interpretation
- If overflow_action is ignore, don't treat as an error

The main driver for this release is to update the kerberos code. It could 
leak memory on certain error conditions. Also added in this release is 
support for records with more than 36 fields. Auditing execve calls would be 
the only way that it might have fell short. Now the field array is realloced 
bigger on demand. And one last item is that the kernel module name was not 
being interpreted correctly. Due to the field name being the same as a file 
path, it was being processed like a path instead of an escaped name.

SHA256: fd9570444df1573a274ca8ba23590082298a083cfc0618138957f590e845bc78

Please let me know if you run across any problems with this release.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string

[Steve Grubb]

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 the field.
> 
> Sample record:
>   type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0
> fan_info=3F
> 
> Suggested-by: Paul Moore 
> Signed-off-by: Richard Guy Briggs 
> ---
>  kernel/auditsc.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index f000fec52360..0f747015c577 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len,
> char *buf)
> 
>   if (!(len && buf)) {
>   audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> -   "resp=%u fan_type=0 fan_info=?", response);
> +   "resp=%u fan_type=0 fan_info=3F", response); /* "?" */
>   return;
>   }
>   while (c >= sizeof(struct fanotify_response_info_header)) {
> + struct audit_context *ctx = audit_context();
> + struct audit_buffer *ab;
> +
>   friar = (struct fanotify_response_info_audit_rule *)buf;
>   switch (friar->hdr.type) {
>   case FAN_RESPONSE_INFO_AUDIT_RULE:
>   if (friar->hdr.len < sizeof(*friar)) {
> - audit_log(audit_context(), GFP_KERNEL, 
> AUDIT_FANOTIFY,
> -   "resp=%u fan_type=%u 
> fan_info=(incomplete)",
> -   response, friar->hdr.type);
> + ab = audit_log_start(ctx, GFP_KERNEL, 
> AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u 
> fan_type=%u fan_info=",
> +  response, 
> friar->hdr.type);
> +#define INCOMPLETE "(incomplete)"
> + audit_log_n_hex(ab, INCOMPLETE, 
> sizeof(INCOMPLETE));
> + audit_log_end(ab);
> + }
>   return;
>   }
> - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> -   "resp=%u fan_type=%u fan_info=%u",
> -   response, friar->hdr.type, friar->audit_rule);
> + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u 
> fan_info=",
> +  response, friar->hdr.type);
> + audit_log_n_hex(ab, (char *)>audit_rule,
> + sizeof(friar->audit_rule));

One thing to point out, the structure has a member audit_rule. It is
probably better to call it rule_number. This is because it has nothing to
do with any actual audit rule. It is a rule number meant to be recorded by
the audit system.

Also, that member is a __u32 type. Hex encoding that directly gives back a
__u32 when decoded - which is a bit unexpected since everything else is
strings. It would be better to convert the u32 to a base 10 string and then
hex encode that. A buffer of 12 bytes should be sufficient.

Thanks,
-Steve

> + audit_log_end(ab);
> +
> + }
>   }
>   c -= friar->hdr.len;
>   ib += friar->hdr.len;




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string

[Steve Grubb]

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 was 63? I think this
> > will work better to leave everything 0 with old user space.
> 
> Well, if it is to be consistently hex encoded, that corresponds to "?"

I suppose this OK.

> if it is to be interpreted as a string.  Since the fan_type is 0,
> fan_info would be invalid, so a value of 0 would be entirely reasonable,
> hex encoded to fan_info=00.  It could also be hex encoded to the string
> "(none)".  If you wanted "0" for fan_type=FAN_RESPONSE_INFO_AUDIT_RULE,
> that would be fan_info=30 if it were interpreted as a string, or
> arguably 3F for an integer of rule (decimal) 63.  Ultimately, fan_type
> should determine how fan_info's hex encoded value should be interpreted.
> 
> But ultimately, the point of this patch is to hex encode the fan_info
> field value.

Just one last update, I have been able to test the patches with the user 
space application and it appears to be working from the PoV of what is sent 
is what's in the audit logs. I'm not sure how picky old kernels are wrt the 
size of what's sent. But an unpatched 5.19 kernel seems to accept the larger 
size response and do the right thing.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string

[Steve Grubb]

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): resp=1 fan_type=0
> fan_info=3F

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 was 63? I think this will work 
better to leave everything 0 with old user space.

-Steve
 
> Suggested-by: Paul Moore 
> Signed-off-by: Richard Guy Briggs 
> ---
>  kernel/auditsc.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index f000fec52360..0f747015c577 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len,
> char *buf)
> 
>   if (!(len && buf)) {
>   audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> -   "resp=%u fan_type=0 fan_info=?", response);
> +   "resp=%u fan_type=0 fan_info=3F", response); /* "?" 
*/
>   return;
>   }
>   while (c >= sizeof(struct fanotify_response_info_header)) {
> + struct audit_context *ctx = audit_context();
> + struct audit_buffer *ab;
> +
>   friar = (struct fanotify_response_info_audit_rule *)buf;
>   switch (friar->hdr.type) {
>   case FAN_RESPONSE_INFO_AUDIT_RULE:
>   if (friar->hdr.len < sizeof(*friar)) {
> - audit_log(audit_context(), GFP_KERNEL, 
AUDIT_FANOTIFY,
> -   "resp=%u fan_type=%u 
fan_info=(incomplete)",
> -   response, friar->hdr.type);
> + ab = audit_log_start(ctx, GFP_KERNEL, 
AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u 
> fan_type=%u 
fan_info=",
> +  response, friar-
>hdr.type);
> +#define INCOMPLETE "(incomplete)"
> + audit_log_n_hex(ab, INCOMPLETE, 
sizeof(INCOMPLETE));
> + audit_log_end(ab);
> + }
>   return;
>   }
> - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> -   "resp=%u fan_type=%u fan_info=%u",
> -   response, friar->hdr.type, friar->audit_rule);
> + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u 
fan_info=",
> +  response, friar->hdr.type);
> + audit_log_n_hex(ab, (char *)>audit_rule,
> + sizeof(friar->audit_rule));
> + audit_log_end(ab);
> +
> + }
>   }
>   c -= friar->hdr.len;
>   ib += friar->hdr.len;




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: LSM stacking in next for 6.1?

[Steve Grubb]

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 sessionid in /proc//status  ?

This has been needed for 10 - 15 years.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Trying to understand audisp-remote network behavior

[Steve Grubb]

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 take away from that is you should only
> turn on heartbeats if you have some unusual requirement.

This has to be coordinated between the client and server as many of these 
setting need to be. I can add some discussion to the man page that this is 
recommended.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Trying to understand audisp-remote network behavior

[Steve Grubb]

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 be related to the fragility (sadly the Kerberos support
> does make it trivial to completely hang the server, but that's another
> issue).

2 Weeks ago I wrote a model to go looking for certain kinds of problems in 
kerberos. The results were that it's probably leaking memory. And on the 
client side, I don't think it was fully resetting all the kerberos variables 
on failure - which may be contributing to the problems.

> This is on RHEL 7 which ships with audit-2.8.5, but as far as
> I can tell the relevant code hasn't changed much from there to what
> is on GitHub.

There are differences. I'd trust the current code in github more than the old 
code.

> After staring at the code a lot and doing some experiments, here's what
> I believe to be true.  I'll gladly take corrections for anything I get
> wrong.
> 
> - If a connection has _never_ been made successfully by audisp-remote,
>   it will retry the connection (in theory there's a limit to retries,
>   but that seems to be per-message; it will retry on every new message).
>   Fine, that seems reasonable.

In github, the first connection should do unlimited retries.

> - If the connection is lost for almost any reason (see below), the
> connection is never retried using the default configuration.  There might
> be some corner cases where a retry can happen, but in my experience that
> is rare. Once it's gone, it never gets retried, and audit messages build
> up until the queue overflows.

The behavior for what to do became a configuration item around 3.0.

> - In theory if a graceful shutdown is received by audisp-remote (either
>   a zero-length read or a "ENDING" audit message), then retries can
>   happen; this is indicated by the "remote_ended" flag in the code.

This would happen if, for example, the aggregating server needed to reboot.

>   But
>   in my experience that is rare; during my experiments when I rebooted
>   our audit server that message was never sent (I guess the audit server
>   stop was received after the interfaces were shut down).  If the audit
>   server crashes or you have a network failure, you end up getting an
>   error on a write and then the network is marked down and you get into
>   never-retry state.
> 
> - If you turn on heartbeats via heartbeat_timeout, the network connection
>   _will_ retry when a heartbeat is sent.  However, the subtle issue here
>   is that a heartbeat is only sent when there are no incoming audit
> messages within the heartbeat timeout.

It is advisable to use the heartbeat option. This way each end can detect the 
other "disappeared" for some reason.

> The key issue seems to be in this part of the loop in main() (this section
> is entered when audisp-remote receives an audit record):
> 
> // See if input fd is also set
> if (FD_ISSET(ifd, )) {
> do {
> if (remote_fgets(event, sizeof(event),
> ifd)) { if (!transport_ok && remote_ended && (config.remote_ending_action
> == FA_RECONNECT || !connected_once)) { quiet = 1;
> if (init_transport() ==
> ET_SUCCESS)
> { remote_ended = 0; connected_once = 1; }
> quiet = 0;
> }
> 
> In short, when a new audit record is received, init_transport()
> (which tries to connect to the audit server) is only called _IF_ the
> connection is down (transport_ok == 0) _and_ remote_ended is true _and_
> remote_ending_action is set to FA_RECONNECT (the default) _or_ there
> hasn't been at least one successful connection (connected_once == 0).
> 
> The problem with that is at least in our environment remote_ended is
> never set to 1, so when the connection drops it is never retried, and
> there aren't any other entry points in the normal event loop that would
> ever cause the connection to retry.

I want to think this has been fixed in the current code. It is one of the 
subtle changes since 2.8.5.

> The heartbeat code calls relay_event() directly (code that sends audit
> events normally calls send_one() which returns if transport_ok is false)
> and relay_event() calls either relay_sock_ascii() or relay_sock_managed()
> and those two functions will call init_transport() if the network
> connection is down.  But as mentioned above, you need to make sure that
> you try to send a heartbeat every so often; if you have a server generating
> audit messages constantly then there won't be a heartbeat if you set the
> heartbeat timeout too high.
> 
> You _can_ get a network connection retry if you 

Re: Be careful with rules

[Steve Grubb]

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 off-list so I figured
> I would add a quick comment here :)
> 
> As a reminder, elevated privilege is needed to both add/remove/modify
> audit rules as well as the loaded SELinux policy (affecting the
> validity of the relevant security labels).  Also, as Lenny already
> mentioned, if an invalid security label is used, the kernel will
> notify the admin via the kernel log.

Wouldn't it be better if the kernel knew the rule was invalid to return 
EINVAL so that rule loading stops or becomes an error return from auditctl? A 
long time ago, there was no way from user space to check a type or a role or 
an selinux user for validity. Can that be done now? Is there an API for it?

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: What does "---" in audit.log timestamp / event-id field mean?

[Steve Grubb]

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=2275
> pid=16746 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000
> egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm=4C5320546872656164
> exe="/usr/lib/firefox-esr/firefox-esr" subj==unconfined key="delete"
> type=CWD msg=audit(1652321038.100:23444): cwd="/home/sam"
> type=PATH msg=audit(1652321038.100:23444): item=0
> name="/home/sam/.mozilla/firefox/baey2He4.default/" inode=15861713
> dev=fe:01 mode=040700 ouid=1000 ogid=1000 rdev=00:00 nametype=PARENT
> cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH
> msg=audit(1652321038.100:23444): item=1
> name="/home/sam/.mozilla/firefox/baey2He4.default/webappsstore.sqlite-wal"
> inode=15860647 dev=fe:01 mode=0100644 ouid=1000 ogid=1000 rdev=00:00
> nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
> type=PROCTITLE msg=audit(1652321038.100:23444):
> proctitle="/usr/lib/firefox-esr/firefox-esr"
> 
> I.e. there is an incomplete timestamp and no event ID in the first line of
> the event "16523210---".

I have never seen such a problem. Looking at both the kernel and userspace 
code, I do not see what could prossibly do this. There is no code with 
exactly 3 dashes in the audit user space or kernel.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v2 0/3] fanotify: Allow user space to pass back additional audit info

[Steve Grubb]

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 inherently contains additional context for the
> > decision. If this information were available in the audit trail, policy
> > writers can close the loop on debugging policy. Also, if this additional
> > information were available, it would enable the creation of tools that
> > can suggest changes to the policy similar to how audit2allow can help
> > refine labeled security.
> > 
> > This patch defines 2 additional fields within the response structure
> > returned from user space on a permission event. The first field is 16
> > bits for the context type. The context type will describe what the
> > meaning is of the second field. The audit system will separate the
> > pieces and log them individually.
> > 
> > The audit function was updated to log the additional information in the
> > AUDIT_FANOTIFY record. The following is an example of the new record
> > format:
> > 
> > type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_ctx=17
> 
> It might have been a good idea to tag this as RFC...  I have a few
> questions:
> 
> 1. Where did "resp=" come from? 

This is an abbreviation for the response field of struct fanotify_response. I 
wanted to keep it short to save bytes.

> It isn't in the field dictionary.  It seems like a needless duplication of
> "res=".  If it isn't, maybe it should have a "fan_" namespace prefix and
> become "fan_res="?

At this point it's been interpretted for years.
 
> 2. It appears I'm ok changing the "__u32 response" to "__u16" without
> breaking old userspace.  Is this true on all arches?

If done carefully. Old user space won't try to use the new capabilities. The 
only trick is new user space/old kernel.

> 3. What should be the action if response contains unknown flags or
> types?  Is it reasonable to return -EINVAL?

The original patch was designed to allow the response metadata to take on 
various different meanings based on new usage. The original patch only defined 
a rule order numbering which if something else wanted to send it's own 
metadata about a decision, a new patch could layer on top of this without 
interfering.

If this is an access decision that is rejected with EINVAL (and assuming 
future decisions will also be formed the same way), the whole system is 
getting ready to lock up - even though a real answer is in the response.

> 4. Currently, struct fanotify_response has a fixed size, but if future
> types get defined that have variable buffer sizes, how would that be
> communicated or encoded?

I hadn't considered that as it would be too much of a change that I would be 
uncomfortable doing. That could be a future evolution if it's ever needed.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH 1/2] audit: add call argument to socketcall auditing

[Steve Grubb]

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 from the
> audit log:
> 
> type=SOCKETCALL msg=audit: call=1 nargs=3 a0=10 a1=3 a2=c

The call argument is in arg0 in the syscall record

type=PROCTITLE msg=audit(1651597634.301:1034): proctitle="./test"
type=SOCKADDR msg=audit(1651597634.301:1034): 
saddr=02357F013030303030303030
type=SOCKETCALL msg=audit(1651597634.301:1034): nargs=3 a0=3 a1=fff47510 
a2=10
type=SYSCALL msg=audit(1651597634.301:1034): arch=4003 syscall=102 
success=no exit=-111 a0=3 a1=fff47520 a2=f7f306cb a3=3502 items=0 
ppid=10425 pid=10428 auid=325 uid=1325 gid=1325 euid=1325 suid=1325 
fsuid=1325 egid=1325 sgid=1325 fsgid=1325 tty=pts2 ses=3 comm="test" exe="/
home/socketcall/test" 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
key="32bit-abi"

which user space translates into:

type=PROCTITLE msg=audit(05/03/2022 13:07:14.301:1034) : proctitle=./test 
type=SOCKADDR msg=audit(05/03/2022 13:07:14.301:1034) : saddr={ 
saddr_fam=inet laddr=127.0.0.1 lport=53 } 
type=SOCKETCALL msg=audit(05/03/2022 13:07:14.301:1034) : nargs=3 a0=0x3 
a1=0xfff47510 a2=0x10 
type=SYSCALL msg=audit(05/03/2022 13:07:14.301:1034) : arch=i386 
syscall=socketcall(connect) success=no exit=ECONNREFUSED(Connection refused) 
a0=connect a1=0xfff47520 a2=0xf7f306cb a3=0x3502 items=0 ppid=10425 
pid=10428 auid=sgrubb uid=sgrubb gid=sgrubb euid=sgrubb suid=sgrubb 
fsuid=sgrubb egid=sgrubb sgid=sgrubb fsgid=sgrubb tty=pts2 ses=3 comm=test 
exe=/home/test/socketcall/test subj=unconfined_u:unconfined_r:unconfined_t:s0-
s0:c0.c1023 key=32bit-abi

Nothing is missing.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH] audit: do a quick exit when syscall number is invalid

[Steve Grubb]

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 invalid/ENOSYS
> > > > syscalls, I would consider that a bug which should be fixed.
> > > 
> > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better
> > > be forcible or be a rule that can be configure? I think configure is
> > > better.
> > 
> > It isn't clear to me exactly what you are asking, but I would expect
> > the existing audit syscall filtering mechanism to work regardless if
> > the syscall is valid or not.
> 
> Thanks, I try to make it more clear. We found that auditctl would only
> set rule with syscall number (>=0 && <2047). So if userspace using
> syscall whose number is (<0 || >=2047), there seems no meaning for
> kernel audit to handle it, since this kind of syscall will never hit
> any audit rule(this rule could not be set by auditctl).

This limit is imposed by:

/usr/include/linux/audit.h

struct audit_rule_data {
...
__u32   mask[AUDIT_BITMASK_SIZE]; /* syscall(s) affected */

Where   #define AUDIT_BITMASK_SIZE 64

So, 64 * 32 = 2048

-Steve

> By the way it's a little strange for auditctl(using libaudit.c) to limit
> syscall number (>=0 && <2047)(see audit_rule_syscall_data()), especially
> we know NR_syscalls is the real limit in kernel, you can see how other
> kernel code to the similar thing in ftrace_syscall_enter():
> 
>   static void ftrace_syscall_enter(void *data, struct pt_regs
>   *regs, long id)
>   {
>   ...
>   syscall_nr = trace_get_syscall_nr(current, regs);
>   if (syscall_nr < 0 || syscall_nr >= NR_syscalls)
>   return;
>   ...
>   }
> 
> Thanks.
> 
> > Beware that there are some limitations
> > to the audit syscall filter, which are unfortunately baked into the
> > current design/implementation, which may affect this to some extent.
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://listman.redhat.com/mailman/listinfo/linux-audit




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

audit-3.0.8 released

[Steve Grubb]

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 the reinitializing of the plugin queue
- Fix path normalization in auparse (Sergio Correia)
- In libaudit, handle ECONNREFUSED for network uid/gid lookups (Enzo 
Matsumiya)
- In audisp-remote, fix hang with disk_low_action=suspend (Enzo Matsumiya)
- Drop ProtectHome from auditd.service as it interferes with rules

The main driver for this release is that there are a number of bugs that have 
been discovered recently. Some of these have been there for a while such as 
the ProtectHome systemd option. The big take away is anyone adding lots of 
systemd hardening options might have some very hard to debug problems.

There was a problem with the plugin queue where a certain combination of 
adding/removing plugins with the queue overflowing caused the queue to not 
restart like it should.

The path normalization issue was causing path's not to be returned when 
interpreted.

SHA256: b5f4d9b9ad69381ee18f33d3d918326aa52861509c901143f8a8c4ed5caa8913

Please let me know if you run across any problems with this release.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Bug in Queue Statistics?

[Steve Grubb]

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 ruleset to reduce the number of events logged which had
> brought down these errors significantly.



> I am not sure but the only way I can think that max plugin queue depth used
> can be 4294967295 (despite the maxlimit being set to 25000) is if we
> dequeue an event before it has been enqueued. Also, the current plugin
> queue depth suggests that events are being dequeued continuously leading
> to the value decreasing from 4294967295 to 4294967240?

I have a feeling this is hard to get into, but is something like the queue 
gets suspended, reconfigure gets rid of plugins, another reconfigure adds back 
plugins and this resets the queue depth to 0, but there are events. As it 
dequeues them it starts getting negative numbers, but the variable is undined 
int hence the very large numbers.

I changed the way that init and reconfigure interact in commit 514d2bd. When 
the queue is destroyed, it resets all the numbers. Otherwise it will now 
leave them alone unless q_depth is zero - which means we need to reallocate a 
queue.

> 2.
> 
> Another update that I would like to make is currently, if we reload the
> auditd configuration instead of restarting, although the configuration
> changes, we do not reset some of the queue statistic variables which I feel
> is incorrect.
> 
> https://github.com/linux-audit/audit-userspace/blob/770e4f538103f8a055f46c0
> 4a9e2514f88f175c3/src/auditd-event.c#L1466
> 
> Ex- If q_depth=400 and the queue overflows, the overflowed variable is set
> to 1. On changing the q_depth value to say 1 and doing a reload, the
> queue size has changed and basically so has the queue. I feel here we
> should reset some of the queue statistic variables like overflowed as it is
> incorrect to say that in it's current form the queue has overflown. This
> variable is not reset and I feel that it should be.

This sounds reasonable. Commit a8d7515 should fix this.

> If agreed that this is a reasonable change, would it be ok if I submit a PR
> for the same?

It's a 1 liner. Thanks, though.

> Also, is it possible that point 2 is causing issues leading to point 1
> errors?

No.

> 3. Would also like to improve the manpage documentation related to
> /var/run/auditd.state. Currently it states that it is a dump of the 
> internal state. I would like to change that to provide a little more
> detail about what the internal state contains - such as queue statistics,
> priority etc.

That might be a lot to document. I don't know if anything else will get 
added, but if that happens, we'll have to document that. If this was done, 
I'd say it should go in the auditd man page.

> Apart from that I feel that we can also add an additonal field to the
> auditd.state file as to when the queue has overflown which may make it
> easier to perform ausearch related queries with start time and end time.

Would having it record down to the second be enough? IOW, no sub-second time 
stamp. If just the second is good enough, I can add that. It's only a couple 
lines of code.

> If any of the changes are worth contributing to I would be happy to make
> the said changes.

I don't plan to write a description of the state report. I'll take a PR, 
though.

Best,
-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Bug in Queue Statistics?

[Steve Grubb]

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,
-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Alert when auditd is stopped

[Steve Grubb]

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=  clause to the auditd.service file that starts a one shot service 
of that you write which sends you the alert however you need it sent.

> Is it possible  to forbid altogether to stop auditd ?

The intended systemd configuration does not allow stopping auditd by dbus. It 
is intended to be controlled by the service command. The stop script sends a 
signal to auditd. So, removing the script won't work since any root user can 
send the TERM or KILL signal. I don't think systemd can limit signals 
received by a daemon. But it can restart a daemon if it fails. Auditd places 
an ignore on all signals except the ones it expects such as TERM. The KILL 
and STOP signals cannot be blocked.

> Can we still stop auditd when the rules are made immutable ?

Yes. The rules are in the kernel. Making them immutable tells the kernel not 
to accept any more rules. It doesn't affect auditd.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Newer versions of audit missing information?

[Steve Grubb]

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, everything is there.
> 
> Is there another way to monitor a directory so we know which files were
> modified / removed?

Well, you can always do  ausearch -k test --raw | aureport -f

I'll take a look and see if I can spot what has changed and how this could be 
fixed.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: audit user space build problems

[Steve Grubb]

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 think this is related
> to gcc-12 since it's the obvious change.
> 
> However, the problem is a combination of 2 things:
> 
> 1) SWIG is making buggy code
> 2) The kernel changed to using flexible array members
> 
> The issue specifically is with struct audit_rules_data. At the bottom, it
> was using buf[0];  But on 5.17, it uses buf[];  It turns out that gcc-12
> is just a coincidence and anything using gcc-12 also has the newest
> kernel.
> 
> The options are:
> 1) Report this as a SWIG bug and wait
> 2) Rewrite the libaudit python bindings to not use SWIG
> 3) Ask for buf[0]; to be reinstated in the kernel.
> 
> Of these, I think option 2 is the only viable long term option. It will
> take some time to write new python bindings that preserve the SWIG api.
> 
> 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
> approaches.

An update on this topic...I have worked around this on rawhide. The temporary 
fix is kind of ugly and I also have no idea how long this temporary fix will be 
needed. Rewriting the python bindings will be a big task. Anyways...the first 
patch can be found here:

https://src.fedoraproject.org/rpms/audit/blob/rawhide/f/audit-3.0.8-flex-array-workaround.patch

Prior to applying the patch, I do this is the %prep part of the spec file:

cp /usr/include/linux/audit.h lib/

then the patch applies cleanly. The only problem is that if you leave it this 
way, then you wind up with other packages not building because they can't find 
audit.h. (See bz 2057735 for example) The fix for this is after the audit 
scripts do the install to the buildroot, you need to undo the change in 
libaudit.h. That patch can be found here:

https://src.fedoraproject.org/rpms/audit/blob/rawhide/f/audit-3.0.8-undo-flex-array.patch

After that, rpm grabs all the files and everything works as intended. As I 
said before, this is an ugly fix...but it works for now.

Hope this helps with packaging...

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: audit user space build problems

[Steve Grubb]

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
> approaches.

You can find a patch that solves this here:
http://people.redhat.com/sgrubb/files/audit-3.0.8-flex-array-workaround.patch

Before applying this patch, the build script needs to copy
/usr/include/linux/audit.h to lib/ in the build directory.

Cheers,
-Steve




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Removing Audit-libs, Python3-audit

[Steve Grubb]

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).
> 
> I have  exclude=audit-libs,python3-audit in /etc/yum.conf
> 
> But, it keeps on reinstalling.

rpmreaper is a good tool to check dependencies. On my system is shows these 
packages pull it in:

5.4M ┌─< python3-policycoreutils   3.3-1.fc35.noarch
  o 1.3M ├─< setroubleshoot-server 3.3.28-3.fc35.x86_64
336K python3-audit 3.0.8-1.fc35.x86_64  

audit-libs is likely impossible to remove. Pam and shadow-utils link against 
it. Unfortunately, systemd turns auditing on. But if you boot with the kernel 
audit=0 option and disable the systemd-journald-audit.socket, you should not 
get any audit events.

Hope this helps...

-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

audit user space build problems

[Steve Grubb]

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 combination of 2 things:

1) SWIG is making buggy code
2) The kernel changed to using flexible array members

The issue specifically is with struct audit_rules_data. At the bottom, it was 
using buf[0];  But on 5.17, it uses buf[];  It turns out that gcc-12 is just 
a coincidence and anything using gcc-12 also has the newest kernel.

The options are:
1) Report this as a SWIG bug and wait
2) Rewrite the libaudit python bindings to not use SWIG
3) Ask for buf[0]; to be reinstated in the kernel.

Of these, I think option 2 is the only viable long term option. It will take 
some time to write new python bindings that preserve the SWIG api.

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 approaches.

Just wanted to let everyone know that new builds in distributions are running 
into a problem. And a real fix will take a while.

Best,
-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Maximum Value for q_depth

[Steve Grubb]

Hello,

On Tuesday, January 18, 2022 1:36:40 AM EST Amjad Gabbar wrote:
> Reaching out regarding the same issue of syslog containing *"auditd
> dispatch error (pipe full) event lost messages". *
> 
> Post excluding the default events(LOGIN, USER_START etc) mentioned in our
> previous chat, there has been a significant drop in the log volume and
> hence I was expecting these error messages to be resolved.
> 
> But unfortunately, even after increasing the dispatcher queue size(q_depth)
> and changing disp_qos to become lossless , I am still seeing mentions of
> these pipe full errors in my syslog.
> The surprising thing is if I try to take a look at the events/keys causing
> this issue, there doesn't seem to be a lot of events for messages to be
> dropped.

Dispatcher plugins can also cause things to get backed up. You mention that 
you have the af_unix plugin. Whatever reads from that needs to unload events 
quickly. It's recommended for the plugin to have 2 threads, one to dequeue 
and one to process the event. It should have storage to hold events if it's 
processing gets behind.


> Ex- Using the command *"aureport --summary -ts  messages start reported in syslog > -te < end time  of dropped messages
> end reported in syslog > -i (-x/-u/--key)"*, the total events are around
> 2000 during this time period. The dispatcher queue size is close to 25,000,
> So I am not really sure why the dispatcher is unable to handle these
> messages. The queue size is sufficient enough to handle 10x the total
> events being seen.

Its entirely depending on the plugin to grab it's event.

> Some other theoretical questions I had surrounding this are:
> 
> 
>- The audit daemon picks events from the kernel buffer and sends it to
>the dispatcher buffer. Who writes these logs to /var/log/audit.log - is
> it the daemon or the dispatcher?

The daemon

> And also, are the total events reported
> in /var/log/audit.log inclusive of the dropped events reported in syslog
> or exclusive?

It writes to the log and then dispatches the event.

> i.e is it possible that all the events have been recorded in
> audit.log but syslog has an issue in keeping up with the events as it is
> the only plugin that is being used by the dispatcher.

You previously mentioned an af_unix plugin. That would be my guess. You can 
disable the syslog plugin and find out if it's the cause.

>- Is there a way to find out what is the total number of events dropped
>by the dispatcher?

I don't think anything keeps metrics on that.

>- In auditd v3+, the daemon itself handles dispatching capabilities. So,
> what does q_depth refer to in this scenario?

The internal queue between the logging thread and the dispatching thread.

>- In the man pages for different distros for disp_qos the following
>statement is common - " There is a 128k buffer between the audit daemon
>and dispatcher." 

This buffer is the kernel inter-process pipe size. There are up to 4 buffers 
in the 2.8 series. The backlog, the inter-process kernel buffer between 
auditd and audispd, a buffer in audispd, and the inter-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 different buffer. The 128k refers to the inter-process pipe buffer.

-Steve

> On Tue, Dec 21, 2021 at 2:39 PM Steve Grubb  wrote:
> > 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
> > > running per minute as a result of which multiple different
> > > events(LOGIN,
> > > USER_END,CRED_DISP etc) are generated each time a cron job runs. As we
> > > do
> > > not enable SELinux, disabling these thing use subj_type=crond_t is not
> > > a
> > > viable option.
> > > 
> > > 1. I have tried the following way to exclude using msg_type and exe
> > > together and it seems to work.
> > > 
> > > -a exclude,always -F msgtype=MAC_IPSEC_EVENT -F exe=/usr/sbin/cron
> > > -a exclude,always -F msgtype=USER_AUTH -F exe=/usr/sbin/cron
> > > -a exclude,always -F msgtype=USER_ACCT -F exe=/usr/sbin/cron
> > > -a exclude,always -F msgtype=CRED_REFR -F exe=/usr/sbin/cron
> > > -a exclude,always -F msgtype=CRED_DISP -F exe=/usr/sbin/cron
> > > -a

audit-3.0.7 released

[Steve Grubb]

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 logging is suspended
- Update the capabilities lookup table to match 5.16 kernel
- Improve interpretation of renamat & faccessat family of syscalls
- Update syscall table for the 5.16 kernel
- Reduce dependency from initscripts to initscripts-service

The main driver for this release is simply getting something out that matches 
the recently released 5.16 kernel.

SHA256: 8b4c78632a9301a1c7f859b0e38fc0b9c260b8214d6b7c771bf28b3d73a62597

Please let me know if you run across any problems with this release.

-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Mapping of Audit rule to Record Type Generated + chmod log query

[Steve Grubb]

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 hooked and collect information
> Would you have any reference links that would help me understand where
> these hooks that collect information are placed?

They start somewhere in this general area:
https://elixir.bootlin.com/linux/latest/source/include/linux/audit.h#L330

There are many hooks. The auxiliary record types are in the 1300 block:
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/audit.h#L89

The one exception is AUDIT_REPLACE which was mistakenly placed in this block. 
It should have been in the 1000 block.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Mapping of Audit rule to Record Type Generated + chmod log query

[Steve Grubb]

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 of SYSCALL and CWD. While a watch for execution
> (-p x) on a file would generate a SYSCALL, EXECVE and CWD.
> 
> Similarly, is there a way to know what record types the different audit
> rule types (file watches, syscalls) may generate?

There are 2 kinds of events, simple and compound. The simple events are 
typically standalone such as something originating from user space. 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 hooked and collect information. When the syscall exits, then it 
dumps all the collected auxiliary records.,


> -
> 
> Question 2
> I am trying to decipher a chmod related log entry. My audit rule is
> -w /etc/passwd -p wa -k passwd_mod
> 
> I thereafter ran a "chmod 744 /etc/passwd" . I received a SYSCALL record
> type with the following parameters
> type=SYSCALL msg=audit(1641846347.980:1326): arch=c03e syscall=268
> success=yes exit=0 a0=ff9c a1=1a600f0 a2=1a4 a3=3c0 items=1
> ppid=6639 pid=6781 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=pts6 ses=4294967295 comm="chmod" exe="/bin/chmod"
> 
> I'm trying to decipher whether the above event can give me the exact
> permission passed to the chmod command (755). I understand that execve may
> give it to me easier.

If you use ausearch -i to look at the raw record, it's much easier.

type=SYSCALL msg=audit(01/10/2022 15:25:47.980:1326) : arch=x86_64 
syscall=fchmodat success=yes exit=0 a0=AT_FDCWD a1=0x1a600f0 a2=0644 a3=0x3c0 
items=1 ppid=6639 pid=6781 auid=unset uid=root gid=root euid=root suid=root 
fsuid=root egid=root sgid=root fsgid=root tty=pts6 ses=unset comm=chmod exe=/
bin/chmod

> I see the underlying syscall is fchmodat which accepts 3 arguments
> 
> int dfd, const char __user *filename, umode_t mode
> 
> In which case, in the above log event, would a3=3c0 be the right argument
> to represent the new permission (755)? Or am I reading this incorrectly?

The a2 argument is the one that has the mode. Ausearch shows that it's value 
is 0644.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Maximum Value for q_depth

[Steve Grubb]

Hello,

On Wednesday, December 8, 2021 11:00:50 PM EST Amjad Gabbar wrote:
> Got it. Makes sense to me. Thanks for the explanation Steve.
> 
> One last thing though based on the discussion we had, if the kernel is able
> to offload events even during bursts, wouldn’t setting q_depth
> =backlog_limit be enough?

Depends on the client attached to the af_unix socket. The kernel could have a 
burst and then another. If the client isn't reading the af_unix socket fast 
enough, there could still be  overflows. That said, it is likely to be enough. 
But I'd look into the client app that reads the af_unix socket to see why 
it's taking so long.

> The reason being if there was an overflow on the kernel side, a different
> message would be printed in the logs but because it is all dispatch errors,
> I assume the kernel is able to handle the burst which 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 Amjad Gabbar wrote:
> > > 1. The version of auditd is 1:2.8.4-3 and the plugins are af_unix.conf
> > 
> > and
> > 
> > > syslog.conf for audisp. The q_depth is currently set to 80 and I think
> > > it
> > > calls for an increase but not sure if there is a way to figure out what
> > 
> > the
> > 
> > > proper number would be?
> > 
> > There is no good calculation that I can give you. It depends on the
> > average
> > rate of incoming events and the rate that they can be offloaded to the
> > plugins
> > + some margin in case there is a burst. Looking at the 2.8.5 code, the
> > default is 250.
> > 
> > https://github.com/linux-audit/audit-userspace/blob/2.8_maintenance/init.
> > d/ audispd.conf
> > 
> > So, you should at least set it that high. Maybe a bit higher.
> > 
> > > 2. Another thing I would like to follow up on is the difference between
> > > q_depth and backlog_limit. My assumption was if there is any drop due
> > > to
> > 
> > a
> > 
> > > burst of events it would be addressed by the backlog limit. Just would
> > 
> > like
> > 
> > > some clarification on this and how this is an event dispatcher issue?
> > 
> > The backlog limit is inside the kernel. This is the buffer that holds
> > events
> > that are waiting for the audit daemon to offload them. Once the audit
> > daemon
> > has them, it sends it to the dispatcher which also buffers events because
> > not
> > all plugins are able to receive the events as soon as they arrive at the
> > dispatcher.
> > 
> > So, for brief bursts, the kernel backlog will handle the load. But once
> > they
> > are pulled out of the kernel, the q_depth controls how much to hold
> > waiting
> > for plugins. If this number needs to increase much, then the plugins are
> > having problems. The syslog plugin should be fine. I'd look more at the
> > af_unix plugin. The client that attaches to it needs to unload events
> > quickly. I'd investigate the af_unix client to see if it's the problem.
> > 
> > Cheers,
> > -Steve





--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Maximum Value for q_depth

[Steve Grubb]

Hello,

On Wednesday, December 8, 2021 4:54:52 PM EST Amjad Gabbar wrote:
> 1. The version of auditd is 1:2.8.4-3 and the plugins are af_unix.conf and
> syslog.conf for audisp. The q_depth is currently set to 80 and I think it
> calls for an increase but not sure if there is a way to figure out what the
> proper number would be?

There is no good calculation that I can give you. It depends on the average 
rate of incoming events and the rate that they can be offloaded to the plugins 
+ some margin in case there is a burst. Looking at the 2.8.5 code, the 
default is 250.

https://github.com/linux-audit/audit-userspace/blob/2.8_maintenance/init.d/
audispd.conf

So, you should at least set it that high. Maybe a bit higher.


> 2. Another thing I would like to follow up on is the difference between
> q_depth and backlog_limit. My assumption was if there is any drop due to a
> burst of events it would be addressed by the backlog limit. Just would like
> some clarification on this and how this is an event dispatcher issue?

The backlog limit is inside the kernel. This is the buffer that holds events 
that are waiting for the audit daemon to offload them. Once the audit daemon 
has them, it sends it to the dispatcher which also buffers events because not 
all plugins are able to receive the events as soon as they arrive at the 
dispatcher.

So, for brief bursts, the kernel backlog will handle the load. But once they 
are pulled out of the kernel, the q_depth controls how much to hold waiting 
for plugins. If this number needs to increase much, then the plugins are 
having problems. The syslog plugin should be fine. I'd look more at the 
af_unix plugin. The client that attaches to it needs to unload events 
quickly. I'd investigate the 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 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 events /day. I have seen previous answers
> > > where it was advised to increase the q_depth value to a suitable
> > > number.
> > > 
> > > Based on this, I would like to confirm what is the maximum advisable
> > 
> > value
> > 
> > > q_depth can have/take?
> > 
> > Depends on what you are willing to set it to. You can easily go to 64k,
> > but
> > you really ought to look at the plugins to see why they can't keep up.
> > And
> > of
> > course, are the rules really designed right and you need the million
> > events/
> > day?
> > 
> > -Steve




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Maximum Value for q_depth

[Steve Grubb]

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 events /day. I have seen previous answers
> where it was advised to increase the q_depth value to a suitable number.
> 
> Based on this, I would like to confirm what is the maximum advisable value
> q_depth can have/take?

Depends on what you are willing to set it to. You can easily go to 64k, but 
you really ought to look at the plugins to see why they can't keep up. And of 
course, are the rules really designed right and you need the million events/
day?

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v1] add clock_adjtime to certification rulesets

[Steve Grubb]

Hello Richard,

On Thursday, November 4, 2021 5:01:10 PM EDT Richard Guy Briggs wrote:
> The clock_adjtime syscall is missing from several certification rulesets
> that monitor changes to the system clock.  Add it.
> 
> Please see https://bugzilla.redhat.com/show_bug.cgi?id=1991919
> 
> Signed-off-by: Richard Guy Briggs 
> ---
>  rules/30-nispom.rules  | 4 ++--
>  rules/30-pci-dss-v31.rules | 4 ++--
>  rules/30-stig.rules| 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/rules/30-nispom.rules b/rules/30-nispom.rules
> index e3873ef95069..ecac01a0b4e1 100644
> --- a/rules/30-nispom.rules
> +++ b/rules/30-nispom.rules
> @@ -10,8 +10,8 @@
>  ## Things that could affect time
>  -a always,exit -F arch=b32 -S adjtimex,settimeofday,stime -F key=time-
>  change
> -a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=time-change
> --a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
> --a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
> +-a always,exit -F arch=b32 -S clock_settime,clock_adjtime -F a0=0x0 -F
> key=time-change
> +-a always,exit -F arch=b64 -S clock_settime,clock_adjtime -F a0=0x0 -F
> key=time-change
> # Introduced in 2.6.39, commented out because it can make false positives
> #-a always,exit -F arch=b32 -S clock_adjtime -F key=time-change
> #-a always,exit -F arch=b64 -S clock_adjtime -F key=time-change

Not sure if you saw this, but directly under the change is a rule for that 
syscall, but it's commented out. This is because it is a very noisy event. 
Anyone that wants it can enable it.

-Steve

> diff --git a/rules/30-pci-dss-v31.rules b/rules/30-pci-dss-v31.rules
> index 7062b35f165c..0251bcafcc03 100644
> --- a/rules/30-pci-dss-v31.rules
> +++ b/rules/30-pci-dss-v31.rules
> @@ -77,8 +77,8 @@
>  ## We will place rules to check time synchronization
>  -a always,exit -F arch=b32 -S adjtimex,settimeofday,stime -F
> key=10.4.2b-time-change -a always,exit -F arch=b64 -S
> adjtimex,settimeofday -F key=10.4.2b-time-change --a always,exit -F
> arch=b32 -S clock_settime -F a0=0x0 -F key=10.4.2b-time-change --a
> always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F
> key=10.4.2b-time-change +-a always,exit -F arch=b32 -S
> clock_settime,clock_adjtime -F a0=0x0 -F key=10.4.2b-time-change +-a
> always,exit -F arch=b64 -S clock_settime,clock_adjtime -F a0=0x0 -F
> key=10.4.2b-time-change # Introduced in 2.6.39, commented out because it
> can make false positives #-a always,exit -F arch=b32 -S clock_adjtime -F
> key=10.4.2b-time-change #-a always,exit -F arch=b64 -S clock_adjtime -F
> key=10.4.2b-time-change diff --git a/rules/30-stig.rules
> b/rules/30-stig.rules
> index 234f239cac06..60384f6b247d 100644
> --- a/rules/30-stig.rules
> +++ b/rules/30-stig.rules
> @@ -26,8 +26,8 @@
>  ## Things that could affect time
>  -a always,exit -F arch=b32 -S adjtimex,settimeofday,stime -F
> key=time-change -a always,exit -F arch=b64 -S adjtimex,settimeofday -F
> key=time-change --a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F
> key=time-change --a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F
> key=time-change +-a always,exit -F arch=b32 -S clock_settime,clock_adjtime
> -F a0=0x0 -F key=time-change +-a always,exit -F arch=b64 -S
> clock_settime,clock_adjtime -F a0=0x0 -F key=time-change # Introduced in
> 2.6.39, commented out because it can make false positives #-a always,exit
> -F arch=b32 -S clock_adjtime -F key=time-change
>  #-a always,exit -F arch=b64 -S clock_adjtime -F key=time-change




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [RFC PATCH v7 07/16] ipe: add auditing support

[Steve Grubb]

Hello,

On Friday, October 15, 2021 3:25:47 PM EDT Deven Bowers wrote:
> On 10/13/2021 1:02 PM, Steve Grubb wrote:
> > On Wednesday, October 13, 2021 3:06:26 PM EDT
> > deven.de...@linux.microsoft.com> 
> > wrote:
> >> 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 respect to IPE
> >> itself.
> > 
> > Would you mind sending examples of audit events so that we can see what
> > the end result is? Some people add them to the commit text. But we still
> > need to see what they look like.
> 
> Sure, sorry. I’ll add them to the commit description (and the documentation
> patch at the end) for v8 – In the interest of asynchronous feedback, I’ve
> copied the relevant examples:

Thanks for sending these. This helps.

 
> AUDIT1420 IPE ctx_pid=229 ctx_op=EXECUTE ctx_hook=MMAP ctx_enforce=0
> ctx_comm="grep" ctx_pathname="/usr/lib/libc-2.23.so"
> ctx_ino=532 ctx_dev=vda rule="DEFAULT op=EXECUTE action=DENY"

Question...why do all of these have a ctx_  prefix? Is it possible to trigger 
an audit context so that the audit machinery collects all of this stuff in 
it's own way? Which means you could drop everything execept op, hook, 
enforce, rule, and action.

We also have a field dictionary here:
https://github.com/linux-audit/audit-documentation/blob/main/specs/fields/
field-dictionary.csv

which names the known fields and how they should be formatted. If there is a 
collision where they are something else and cannot be in the same format, 
then we make a new name and hopefully update the dictionary. For example, if 
you are collecting a process id, use pid and not ctx_pid so that it matches a 
known definition.

Also, I don't thnk these events can stand on their own. Who did this action? 
You have the pid, but no uid, auid, or session_id.

Hope this helps...

-Steve

 
> AUDIT1420 IPE ctx_pid=229 ctx_op=EXECUTE ctx_hook=MMAP ctx_enforce=0
> ctx_comm="grep" ctx_pathname="/usr/lib/libc-2.23.so"
> ctx_ino=532 ctx_dev=vda rule="DEFAULT action=DENY"
> 
> AUDIT1420 IPE ctx_pid=253 ctx_op=EXECUTE ctx_hook=MMAP ctx_enforce=1
> ctx_comm="anon" rule="DEFAULT op=EXECUTE action=DENY"
> 
> These three audit records represent various types of results after
> evaluating
> the trust of a resource. The first two differ in the rule that was
> matched in
> IPE's policy, the first being an operation-specific default, the second
> being
> a global default. The third is an example of what is audited when anonymous
> memory is blocked (as there is no way to verify the trust of an anonymous
> page).
> 
> The remaining three events, AUDIT_TRUST_POLICY_LOAD (1421),
> AUDIT_TRUST_POLICY_ACTIVATE (1422), and AUDIT_TRUST_STATUS (1423) have this
> form:
> 
> AUDIT1421 IPE policy_name="my-policy" policy_version=0.0.0
> =
> AUDIT1422 IPE policy_name="my-policy" policy_version=0.0.0
> =
> AUDIT1423 IPE enforce=1
> 
> The 1421 (AUDIT_TRUST_POLICY_LOAD) event represents a new policy was loaded
> into the kernel, but not is not marked as the policy to enforce. The
> 
> The 1422 (AUDIT_TRUST_POLICY_ACTIVATE) event represents a policy that was
> already loaded was made the enforcing policy.
> 
> The 1423 (AUDIT_TRUST_STATUS) event represents a switch between
> permissive and
> enforce, it is added in 08/16 (the following patch)





--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH v3 2/7] add support for the uring filter list

[Steve Grubb]

Hello Richard,

On Monday, November 1, 2021 11:05:49 AM EDT Richard Guy Briggs wrote:
> On 2021-10-29 14:39, Steve Grubb wrote:
> > On Thursday, October 28, 2021 3:59:34 PM EDT Richard Guy Briggs wrote:
> > > Kernel support to audit io_uring operations filtering was added with
> > > commit 67daf270cebc ("audit: add filtering for io_uring records").  Add
> > > support for the "uring" filter list to auditctl.
> > 
> > Might have been good to show what the resulting auditctl command looks
> > like. I think it would be:
> > 
> > auditctl -a always,io_uring  -U  open -F uid!=0 -F key=io_uring
> > 
> > But I wonder, why the choice of  -U rather than -S? That would make
> > remembering the syntax easier.
> > 
> > auditctl -a always,io_uring  -S  open -F uid!=0 -F key=io_uring
> 
> Well, I keep seeing the same what I assume is a typo in your
> communications about io_uring where the "u" is missing, which might help
> trigger your memory about the syntax.

Yeah, but I'm thinking that we can abstract that technicality away and keep 
the syntax the same.

> The io_uring operations name list is different than the syscall list, so
> it needs to use a different lookup table.

Right. So, if you choose an operation that is not supported, you get an 
error. But to help people know what is supported, we can add the lookup to 
ausyscall where  --io_uring could direct it to the right lookup table.

> Have I misunderstood something?

No, but I'm thinking of aesthetics and usability. You already have to specify 
a filter. We don't really need to have completely different syntax in 
addition. Especially since the operations map to the equivalent of a syscall.
 

> > > Signed-off-by: Richard Guy Briggs 
> > > ---
> > > docs/audit.rules.7 |  19 --
> > > docs/audit_add_rule_data.3 |   4 ++
> > > docs/auditctl.8|  10 ++-
> > > lib/flagtab.h  |  11 ++--
> > > lib/libaudit.c |  50 ---
> > > lib/libaudit.h |   7 +++
> > > lib/lookup_table.c |  20 ++
> > > lib/private.h  |   1 +
> > > src/auditctl-listing.c |  52 ++--
> > > src/auditctl.c | 121 -
> > > 10 files changed, 240 insertions(+), 55 deletions(-)
> > 
> > 
> > 
> > > diff --git a/lib/libaudit.c b/lib/libaudit.c
> > > index 54e276156ef0..3790444f4497 100644
> > > --- a/lib/libaudit.c
> > > +++ b/lib/libaudit.c
> > > @@ -86,6 +86,7 @@ static const struct nv_list failure_actions[] =
> > > int _audit_permadded = 0;
> > > int _audit_archadded = 0;
> > > int _audit_syscalladded = 0;
> > > +int _audit_uringopadded = 0;
> > > int _audit_exeadded = 0;
> > > int _audit_filterfsadded = 0;
> > > unsigned int _audit_elf = 0U;
> > > @@ -999,6 +1000,26 @@ int audit_rule_syscallbyname_data(struct
> > > audit_rule_data *rule, return -1;
> > > }
> > > 
> > > +int audit_rule_uringopbyname_data(struct audit_rule_data *rule,
> > > +  const char *uringop)
> > > +{
> > > +   int nr, i;
> > > +
> > > +   if (!strcmp(uringop, "all")) {
> > > +   for (i = 0; i < AUDIT_BITMASK_SIZE; i++)
> > > +   rule->mask[i] = ~0;
> > > +   return 0;
> > > +   }
> > > +   nr = audit_name_to_uringop(uringop);
> > > +   if (nr < 0) {
> > > +   if (isdigit(uringop[0]))
> > > +   nr = strtol(uringop, NULL, 0);
> > > +   }
> > > +   if (nr >= 0)
> > > +   return audit_rule_syscall_data(rule, nr);
> > > +   return -1;
> > > +}
> > > +
> > > int audit_rule_interfield_comp_data(struct audit_rule_data **rulep,
> > > const char *pair,
> > > int flags)
> > > @@ -1044,7 +1065,7 @@ int audit_rule_interfield_comp_data(struct
> > > audit_rule_data **rulep, return -EAU_COMPVALUNKNOWN;
> > > 
> > > /* Interfield comparison can only be in exit filter */
> > > -   if (flags != AUDIT_FILTER_EXIT)
> > > +   if (flags != AUDIT_FILTER_EXIT && flags !=
> > > AUDIT_FILTER_URING_EXIT) return -EAU_EXITONLY;
> > > 
> > > // It should always be AUDIT_FIELD_COMPARE
> > > @@ -1557,7 +1578,8 @@ int audit_rule_fieldpair_data(struct
> > > audit_rule_data
> > > **rulep, const char *