Re: Sycall Rules vs Watch Rules
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 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: [nf PATCH 1/2] netfilter: nf_tables: Audit log setelem reset
On 2023-08-30 17:46, Pablo Neira Ayuso wrote: > On Tue, Aug 29, 2023 at 07:51:57PM +0200, Phil Sutter wrote: > > Since set element reset is not integrated into nf_tables' transaction > > logic, an explicit log call is needed, similar to NFT_MSG_GETOBJ_RESET > > handling. > > > > For the sake of simplicity, catchall element reset will always generate > > a dedicated log entry. This relieves nf_tables_dump_set() from having to > > adjust the logged element count depending on whether a catchall element > > was found or not. > > Applied, thanks Phil Thanks Phil, Pablo. If it isn't too late, please add my Reviewed-by: Richard Guy Briggs - 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: [PATCH] audit: add task history record
; + int i;
> + int required;
> + struct tm tm;
> + char buf[256];
> + char *cp = buf;
> +
> + if (!audit_history_size)
> + return;
> +
> + cp += snprintf(buf, sizeof(buf) - 1, "name=");
> + for (i = 0; i < TASK_COMM_LEN; i++) {
> + const unsigned char c = current->comm[i];
> +
> + if (!c)
> + break;
> + if (isalnum(c) || c == '.' || c == '_' || c == '-' || c == '/')
> {
> + *cp++ = c;
> + continue;
> + }
> + *cp++ = '\\';
> + *cp++ = (c >> 6) + '0';
> + *cp++ = ((c >> 3) & 7) + '0';
> + *cp++ = (c & 7) + '0';
> + }
> + /* Append PID. */
> + cp += snprintf(cp, buf - cp + sizeof(buf) - 1, ";pid=%u",
> +current->pid);
> + /* Append timestamp. */
> + time64_to_tm(ktime_get_real_seconds(), 0, );
> + cp += snprintf(cp, buf - cp + sizeof(buf) - 1,
> +";start=%04u%02u%02u%02u%02u%02u", (int) tm.tm_year +
> 1900,
> +tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, tm.tm_min,
> +tm.tm_sec);
> + /* Terminate the buffer. */
> + if (cp >= buf + sizeof(buf))
> + cp = buf + sizeof(buf) - 1;
> + *cp = '\0';
> + required = cp - buf + 1;
> + /* Make some room by truncating old history. */
> + cp = current->comm_history;
> + i = strlen(cp);
> + while (i + required >= audit_history_size - 3) {
> + char *cp2 = memchr(cp, '>', i);
> +
> + /* Reset history if audit_history_size is too small to
> truncate. */
> + if (!cp2++) {
> + *cp = '\0';
> + return;
> + }
> + i -= cp2 - cp;
> + memmove(cp, cp2, i + 1);
> + }
> + /* Emit the buffer. */
> + if (i) {
> + cp[i++] = '=';
> + cp[i++] = '>';
> + }
> + memcpy(cp + i, buf, required);
> +}
> --
> 2.18.4
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://listman.redhat.com/mailman/listinfo/linux-audit
>
- 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: Comprehensive Documentation on the Linux Audit Framework
On 2023-06-06 18:01, Paul Moore wrote: > On Tue, Jun 6, 2023 at 3:09 PM Steve Grubb wrote: > > On Tuesday, June 6, 2023 6:31:55 PM EDT Vincent Abraham wrote: > > > Thanks. Could you also point to portions in the codebase where these > > > functions are called for monitoring file access? > > > > I'll let Richard or Paul point to the place in the kernel if that's > > necessary. I think there's a fundamental mismatch and it might not matter. > > The audit subsystem in the Linux Kernel is currently found in the core > kernel/ directory: > > % ls -1 kernel/audit* > kernel/audit.c > kernel/auditfilter.c > kernel/audit_fsnotify.c > kernel/audit.h > kernel/auditsc.c > kernel/audit_tree.c > kernel/audit_watch.c I could have sworn I'd sent a reply yesterday afternoon with pointers to three functions to start with, but it didn't make it to the list and I have no record of it... Directives from userspace come in here: https://github.com/linux-audit/audit-kernel/blob/main/kernel/audit.c#L1542 and are processed here: https://github.com/linux-audit/audit-kernel/blob/main/kernel/audit.c#L1204 For file access rules, see https://github.com/linux-audit/audit-kernel/blob/main/kernel/audit_watch.c For directory access rules, if you dare to tread, see https://github.com/linux-audit/audit-kernel/blob/main/kernel/audit_tree.c Once rules are in place, there are hooks all over the kernel to monitor activity in various subsystems. Have a look at audit_log_start() that generates the log messages: https://github.com/linux-audit/audit-kernel/blob/main/kernel/audit.c#L1829 and kauditd_send_queue() which manages the queues: https://github.com/linux-audit/audit-kernel/blob/main/kernel/audit.c#L718 > > ... would be path, kind of access, who is accessing it, program accessing > > it, portions of se linux labeling, and a few other things. > > FYI for everyone on the thread, the generally accepted way to write to > "SELinux" is as one word (no space between the "SE" and "Linux") and > with the first three letters capitalized. I know we can be a little > lazy with capitalization, I definitely am, but writing it as one word > is the important part. > > -- > paul-moore.com - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- 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
On 2023-05-24 10:42, Steve Grubb wrote: > 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. Minor correction: there is a kernel variable (audit_n_rules) that counts the number of syscall rules in place, but it isn't reported directly outside the kernel. This feeds the boolean (struct audit_context)->dummy. > > 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 - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: "service auditd start" fails inside a container
On 2023-05-01 11:01, Daniel Walsh wrote:
> On 4/28/23 14:48, Steve Grubb wrote:
> > 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
>
> I don't believe there is anything to prevent auditd from running within a
> container. You can turn up and down the container to many different levels
> or security separation. There will be some security things that need to be
> turned off.
>
> Running a contianer privileged will turn off almost everything form a
> security perspective, and then running with some of the namespaces shared
> with the host.
>
> Something like
>
> podman run --privileged --network=host --pid=host ... auditimage
>
> Should work.
>
> Later tightening up the security should also be possible, but you would need
> to know what auditd needs access to.
>
> With all that said, I am not sure what you are trying to achieve by
> containerizing the audit daemon.
Audit currently requires access to the root userspace and pid
namespaces, so if the container shares those with the host, it should
run.
There are work items to address this, but they haven't been started in
ernest yet:
https://github.com/linux-audit/audit-kernel/issues/93
dependancies:
https://github.com/linux-audit/audit-kernel/issues/90
https://github.com/linux-audit/audit-kernel/issues/91
https://github.com/linux-audit/audit-kernel/issues/92
https://github.com/linux-audit/audit-kernel/issues/75
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: Clarification Around File System Auditing
On 2023-02-17 16:50, Steve Grubb wrote: > 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. There is essentially an empty list check in __audit_syscall_exit() with the dummy check, based on the number of syscall (or io_uring) rules in place tracked in audit_n_rules. Unfortunately, we can't bail from __audit_syscall_entry() right after setting dummy because other hardwired records can cancel the dummy flag. > -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 im
Re: Auditing nftables changes
On 2023-03-10 11:04, Paul Moore wrote: > On Fri, Mar 10, 2023 at 9:36 AM Steve Grubb wrote: > > On Thursday, March 9, 2023 5:52:28 PM EST Bruce Elrick wrote: > > > Anyway, I think I need to spend some time playing until that "aha!" > > > moment comes. It's feels a lot closer thanks to both of your responses > > > and I really apprecaite the 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. > > Reading Steve's response I'm not sure we use the same terminology, or > perhaps we explain it a bit differently. Regardless, here is a quick > definition that I stick to when discussing audit: > > "audit record": An audit record is a single line in the audit log that > consists of a timestamp, record type (type=XXX), and a series of > fields which are dependent on the record type. Here is an example of > a SYSCALL record: > > type=SYSCALL msg=audit(03/10/2023 10:59:00.797:563) : > arch=x86_64 syscall=bpf success=yes exit=12 a0=BPF_PROG_LOAD > a1=0x7ffde0efc650 a2=0x80 a3=0x13 items=0 ppid=1 pid=2683 > auid=root uid=root gid=root euid=root suid=root fsuid=root > egid=root sgid=root fsgid=root tty=(none) ses=10 comm=systemd > exe=/usr/lib/systemd/systemd > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) > > "audit event": An audit event consists of multiple audit records > grouped together by a single timestamp. Single record audit events > are allowed and do exist. There is no upper bound on the number of > records allowed in an audit event. Here is an example of an audit > event consisting of PROCTITLE, SYSCALL, and BPF audit records: > > type=PROCTITLE msg=audit(03/10/2023 10:59:00.797:563) : > proctitle=(systemd) > type=SYSCALL msg=audit(03/10/2023 10:59:00.797:563) : > arch=x86_64 syscall=bpf success=yes exit=12 a0=BPF_PROG_LOAD > a1=0x7ffde0efc650 a2=0x80 a3=0x13 items=0 ppid=1 pid=2683 > auid=root uid=root gid=root euid=root suid=root fsuid=root > egid=root sgid=root fsgid=root tty=(none) ses=10 comm=systemd > exe=/usr/lib/systemd/systemd > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) > type=BPF msg=audit(03/10/2023 10:59:00.797:563) : > prog-id=172 op=LOAD An "audit event" which is a collection of audit records with the same timestamp and serial number correspond to *one* event of interest to the audit subsystem either due to internal rules or added audit rules that when triggered record audit information into a set of records that are all related to give a larger picture of the circumstances of that event. Configuration changes, being audit rules added, or firewall rules changes, are hardwired. > I hope that helps. > > -- > paul-moore.com > - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: Auditing nftables changes
On 2023-03-09 15:14, Paul Moore wrote:
> On Thu, Mar 9, 2023 at 11:33 AM Bruce Elrick
> wrote:
> >
> > I think I need to clarify where I'm confused ;-)
> >
> > With iptables you could write a rule that would only catch system
> > calls that were for iptables changes. That is, you didn't need to
> > capture *all* setsockopt calls (not that there would be lots of
> > *those*) but rather you could add the a2=64 to only get the
> > op=IPT_SO_SET_REPLACE ones.
> >
> > With netfilter, however, since the control interface is netlink and
> > netlink requires a message to a socket and messages are structs, there
> > is no way to have a similarly narrow audit rule as in the case of
> > iptables.
> >
> > That's the first thing I want to confirm: whether my understanding
> > above is correct?
>
> Yes, you are correct.
>
> > I'm confused because your answer implies I'm correct
> > but you didn't explicitly confirm that my interpretation of how it
> > works was correct.
> >
> > You talk about having an exclude filter on NETFILTER_CFG (or rather
> > exclude everything except NETFILTER_CFG??) but my understanding is
> > that you can only do that filtering after the fact using ausearch or
> > writing some sort of correlation code using the auparse library.
>
> The kernel implements an exclude filter which is described in the
> auditctl(8) manpage:
>
> "Add a rule to the event type exclusion filter list.
> This list is used to filter events that you do not
> want to see. For example, if you do not want to see
> any avc messages, you would using this list to
> record that. Events can be excluded by process ID,
> user ID, group ID, login user ID, message type,
> subject context, or executable name. The action is
> ignored and uses its default of "never".
>
> Taken from https://man7.org/linux/man-pages/man8/auditctl.8.html
>
> However, in my last reply I wasn't advocating for this use of the
> exclude filter, I was simply trying to explain that unless you are
> explicitly excluding the creation of NETFILTER_CFG records via the
> exclude filter you should be seeing NETFILTER_CFG in your audit stream
> with basic auditing enabled.
Bruce, it appears you asked this question on IRC Libera #audit as
"virtuous-sloth". I replied there as Paul has clarified here that all
those configuration changes for iptables and nft should be in the audit
log by default if audit is enabled, because they are considered system
configuration changes which are required by certifications to be
audited by default. This wasn't always the behaviour, and as you asked
about "GHAK124" (https://github.com/linux-audit/audit-kernel/issues/124)
has been fixed and updated. At first, they were dependant on audit
configuration and were missing some iptables events (ghak 25, 35, 43,
44), and nft wasn't monitored at all, but as of upstream v5.8 the
iptables issues are resolved, as of v5.9 nft support was added and as of
upstream v5.13 nft support was tamed a bit due to the unnecessarily
large volume of records produced in the initial nft support. If these
events are not showing up in your logs you may have an older kernel.
Have I understood your problem and does this help clarify things?
> > It just seemed surprising that there is a non-trivial loss of audit
> > functionality but that I could not find any obvious discussion about
> > that. By obvious discussion I mean as explicitly as what I'm trying to
> > say here.
>
> Unfortunately it is a fairly common practice for kernel features to be
> added, and removed, without consulting with the various Linux Kernel
> security developers, e.g. audit, SELinux, LSM, etc. Sometimes we are
> successful in retrofitting the necessary security and/or auditing
> hooks, sometimes we are limited due to design choices.
>
> > The other thing I'm trying to understand is how heavy an audit load
> > would it be to have an audit rule that captures *all* sendmsg calls
> > (well, all except where auid=-1 or auid=${serviceuser_uid}). I don't
> > have a good enough understanding of systems programming to know where
> > and how often the sendmsg is called. Of course I know this is highly
> > dependent on workload, but my knowledge is limited enough that I I can
> > convince myself both that the audit load would be not trivial but
> > still manageable in most cases but also I can convince myself that no
> > same sysadmin would consider running such an audit rule. With file IO
> > it's easy to distinguish that file opens are worth auditing but file
> > reads and writes would be insane to audit. It's not so clear for me
> > for sockets.
>
> Th
Re: [PATCH v2] io_uring,audit: don't log IORING_OP_MADVISE
On 2023-02-10 11:52, Paul Moore wrote: > On Fri, Feb 10, 2023 at 11:00 AM Jens Axboe wrote: > > On 2/10/23 8:39?AM, Paul Moore wrote: > > > On Thu, Feb 9, 2023 at 7:15 PM Jens Axboe wrote: > > >> On 2/9/23 3:54?PM, Steve Grubb wrote: > > >>> On Thursday, February 9, 2023 5:37:22 PM EST Paul Moore wrote: > > >>>> On Thu, Feb 9, 2023 at 4:53 PM Richard Guy Briggs > > >>>> wrote: > > >>>>> On 2023-02-01 16:18, Paul Moore wrote: > > >>>>>> On 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. > > >> > > >> Agree, it's getting a bit anal... FWIW, patch looks fine to me. > > > > > > Call it whatever you want, but the details are often important at this > > > level of code, and when I see a patch author pushing back on verifying > > > that their patch is correct it makes me very skeptical. > > > > Maybe it isn't intended, but the replies have generally had a pretty > > condescending tone to them. That's not the best way to engage folks, and > > may very well be why people just kind of give up on it. Nobody likes > > debating one-liners forever, particularly not if it isn't inviting. > > I appreciate that you are coming from a different space, but I stand > by my comments. Of course you are welcome to your own opinion, but I > would encourage you to spend some time reading the audit mail archives > going back a few years before
Re: [PATCH v2] io_uring,audit: don't log IORING_OP_MADVISE
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.
> 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.
> > Fixes: 5bd2182d58e9 ("audit,io_uring,io-wq: add some basic audit support to
> > io_uring")
> > Signed-off-by: Richard Guy Briggs
> > ---
> > changelog
> > v2:
> > - drop *GETXATTR patch
> > - drop FADVISE hunk
> >
> > io_uring/opdef.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/io_uring/opdef.c b/io_uring/opdef.c
> > index 3aa0d65c50e3..d3f36c633ceb 100644
> > --- a/io_uring/opdef.c
> > +++ b/io_uring/opdef.c
> > @@ -312,6 +312,7 @@ const struct io_op_def io_op_defs[] = {
> > .issue = io_fadvise,
> > },
> > [IORING_OP_MADVISE] = {
> > + .audit_skip = 1,
> > .name = "MADVISE",
> > .prep = io_madvise_prep,
> > .issue = io_madvise,
> > --
> > 2.27.0
>
> --
> paul-moore.com
>
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
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
On 2023-02-08 11:24, Paul Moore wrote: > On Wed, Feb 8, 2023 at 10:27 AM Steve Grubb wrote: > > On Wednesday, February 8, 2023 10:03:24 AM EST Paul Moore wrote: > > > On Wed, Feb 8, 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 m
[PATCH v7 3/3] fanotify, audit: Allow audit to use the full permission event response
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=0
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 | 18 +++---
3 files changed, 22 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..5a5994659b44 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,21 @@ 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 */
+ switch (friar->hdr.type) {
+ case FAN_RESPONSE_INFO_NONE:
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=%u fan_info=0 subj_trust=2
obj_trust=2",
+ response, FAN_RESPONSE_INFO_NONE);
+ break;
+ case FAN_RESPONSE_INFO_AUDIT_RULE:
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=%u fan_info=%X subj_trust=%u
obj_trust=%u",
+ response, friar->hdr.type, friar->rule_number,
+ friar->subj_trust, friar->obj_trust);
+ }
}
void __audit_tk_injoffset(struct timespec64 offset)
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v7 2/3] fanotify: define struct members to hold response decision context
This patch adds a flag, FAN_INFO and an extensible buffer to provide
additional information about response decisions. The buffer contains
one or more headers defining the information type and the length of the
following information. The patch defines one additional information
type, FAN_RESPONSE_INFO_AUDIT_RULE, to audit a rule number. This will
allow for the creation of other information types in the future if other
users of the API identify different needs.
The kernel can be tested if it supports a given info type by supplying
the complete info extension but setting fd to FAN_NOFD. It will return
the expected size but not issue an audit record.
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
Suggested-by: Jan Kara
Link: https://lore.kernel.org/r/20201001101219.ge17...@quack2.suse.cz
Signed-off-by: Richard Guy Briggs
---
fs/notify/fanotify/fanotify.c | 5 +-
fs/notify/fanotify/fanotify.h | 4 ++
fs/notify/fanotify/fanotify_user.c | 86 ++
include/linux/fanotify.h | 5 ++
include/uapi/linux/fanotify.h | 30 ++-
5 files changed, 107 insertions(+), 23 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index a2a15bc4df28..24ec1d66d5a8 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -262,7 +262,7 @@ static int fanotify_get_response(struct fsnotify_group
*group,
}
/* userspace responded, convert to something usable */
- switch (event->response & ~FAN_AUDIT) {
+ switch (event->response & FANOTIFY_RESPONSE_ACCESS) {
case FAN_ALLOW:
ret = 0;
break;
@@ -563,6 +563,9 @@ static struct fanotify_event
*fanotify_alloc_perm_event(const struct path *path,
pevent->fae.type = FANOTIFY_EVENT_TYPE_PATH_PERM;
pevent->response = 0;
+ pevent->hdr.type = FAN_RESPONSE_INFO_NONE;
+ pevent->hdr.pad = 0;
+ pevent->hdr.len = 0;
pevent->state = FAN_EVENT_INIT;
pevent->path = *path;
path_get(path);
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index f899d610bc08..e8a3c28c5d12 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -428,6 +428,10 @@ struct fanotify_perm_event {
u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
+ union {
+ struct fanotify_response_info_header hdr;
+ struct fanotify_response_info_audit_rule audit_rule;
+ };
};
static inline struct fanotify_perm_event *
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index caa1211bac8c..8f430bfad487 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -283,19 +283,42 @@ static int create_fd(struct fsnotify_group *group, const
struct path *path,
return client_fd;
}
+static int process_access_response_info(const char __user *info,
+ size_t info_len,
+ struct fanotify_response_info_audit_rule *friar)
+{
+ if (info_len != sizeof(*friar))
+ return -EINVAL;
+
+ if (copy_from_user(friar, info, sizeof(*friar)))
+ return -EFAULT;
+
+ if (friar->hdr.type != FAN_RESPONSE_INFO_AUDIT_RULE)
+ return -EINVAL;
+ if (friar->hdr.pad != 0)
+ return -EINVAL;
+ if (friar->hdr.len != sizeof(*friar))
+ return -EINVAL;
+
+ return info_len;
+}
+
/*
* Finish processing of permission event by setting it to ANSWERED state and
* drop group->notification_lock.
*/
static void finish_permission_event(struct fsnotify_group *group,
- struct fanotify_perm_event *event,
- u32 response)
+ struct fanotify_perm_event *event, u32
response,
+ struct fanotify_response_info_audit_rule
*friar)
__releases(>notification_lock)
{
bool destroy = false;
assert_spin_locked(>notification_lock);
- event->response = response;
+ event->response = response & ~FAN_INFO;
+ if (response & FAN_INFO)
+ memcpy(>audit_rule, friar, sizeof(*friar));
+
if (event->state == FAN_EVENT_CANCELED)
destroy = true;
else
@@ -306,20 +329,27 @@ static void finish_permission_event(struct fsnotify_group
*group,
}
static int process_access_response(struct fsnotify_group *group,
- struct fanotify_response *response_struct)
+
[PATCH v7 1/3] fanotify: Ensure consistent variable type for response
The user space API for the response variable is __u32. This patch makes
sure that the whole path through the kernel uses u32 so that there is
no sign extension or truncation of the user space response.
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/12617626.uLZWGnKmhe@x2
Signed-off-by: Richard Guy Briggs
Acked-by: Paul Moore
---
fs/notify/fanotify/fanotify.h | 2 +-
fs/notify/fanotify/fanotify_user.c | 6 +++---
include/linux/audit.h | 6 +++---
kernel/auditsc.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index 57f51a9a3015..f899d610bc08 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -425,7 +425,7 @@ FANOTIFY_PE(struct fanotify_event *event)
struct fanotify_perm_event {
struct fanotify_event fae;
struct path path;
- unsigned short response;/* userspace answer to the event */
+ u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
};
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index 4546da4a54f9..caa1211bac8c 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -289,7 +289,7 @@ static int create_fd(struct fsnotify_group *group, const
struct path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- unsigned int response)
+ u32 response)
__releases(>notification_lock)
{
bool destroy = false;
@@ -310,9 +310,9 @@ static int process_access_response(struct fsnotify_group
*group,
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
- int response = response_struct->response;
+ u32 response = response_struct->response;
- pr_debug("%s: group=%p fd=%d response=%d\n", __func__, group,
+ pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
fd, response);
/*
* make sure the response is valid, if invalid we do nothing and either
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 3608992848d3..d6b7d0c7ce43 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -416,7 +416,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(unsigned int response);
+extern void __audit_fanotify(u32 response);
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,7 +523,7 @@ static inline void audit_log_kern_module(char *name)
__audit_log_kern_module(name);
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{
if (!audit_dummy_context())
__audit_fanotify(response);
@@ -679,7 +679,7 @@ static inline void audit_log_kern_module(char *name)
{
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{ }
static inline void audit_tk_injoffset(struct timespec64 offset)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 547c88be8a28..d1fb821de104 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2877,7 +2877,7 @@ void __audit_log_kern_module(char *name)
context->type = AUDIT_KERN_MODULE;
}
-void __audit_fanotify(unsigned int response)
+void __audit_fanotify(u32 response)
{
audit_log(audit_context(), GFP_KERNEL,
AUDIT_FANOTIFY, "resp=%u", response);
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v7 0/3] fanotify: Allow user space to pass back additional audit info
() on FAN_NOFD after process_access_response_info() Link: https://lore.kernel.org/all/cover.1673989212.git@redhat.com v7: - change non FAN_INFO case to "0" - change from if-return to switch(type)-case, which now ignores non-audit info Link: https://lore.kernel.org/all/cover.1675373475.git@redhat.com Richard Guy Briggs (3): fanotify: Ensure consistent variable type for response fanotify: define struct members to hold response decision context fanotify,audit: Allow audit to use the full permission event response fs/notify/fanotify/fanotify.c | 8 ++- fs/notify/fanotify/fanotify.h | 6 +- fs/notify/fanotify/fanotify_user.c | 88 ++ include/linux/audit.h | 9 +-- include/linux/fanotify.h | 5 ++ include/uapi/linux/fanotify.h | 30 +- kernel/auditsc.c | 18 +- 7 files changed, 131 insertions(+), 33 deletions(-) -- 2.27.0 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v2] io_uring,audit: don't log IORING_OP_MADVISE
fadvise and madvise both provide hints for caching or access pattern for
file and memory respectively. Skip them.
Fixes: 5bd2182d58e9 ("audit,io_uring,io-wq: add some basic audit support to
io_uring")
Signed-off-by: Richard Guy Briggs
---
changelog
v2:
- drop *GETXATTR patch
- drop FADVISE hunk
io_uring/opdef.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/io_uring/opdef.c b/io_uring/opdef.c
index 3aa0d65c50e3..d3f36c633ceb 100644
--- a/io_uring/opdef.c
+++ b/io_uring/opdef.c
@@ -312,6 +312,7 @@ const struct io_op_def io_op_defs[] = {
.issue = io_fadvise,
},
[IORING_OP_MADVISE] = {
+ .audit_skip = 1,
.name = "MADVISE",
.prep = io_madvise_prep,
.issue = io_madvise,
--
2.27.0
--
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
On 2023-01-27 19:06, Paul Moore wrote:
> On Fri, Jan 27, 2023 at 6:01 PM Richard Guy Briggs wrote:
> > On 2023-01-27 17:43, Paul Moore wrote:
> > > On Fri, Jan 27, 2023 at 12:24 PM Richard Guy Briggs
> > > wrote:
> > > > Getting XATTRs is not particularly interesting security-wise.
> > > >
> > > > Suggested-by: 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_classes_permissions.md#common-file-permissions
> >
> > The intent here is to lessen the impact of audit operations. Read and
> > Write were explicitly removed from io_uring auditing due to performance
> > concerns coupled with the denial of service implications from sheer
> > volume of records making other messages harder to locate. Those
> > operations are still possible for syscall auditing but they are strongly
> > discouraged for normal use.
>
> We need to balance security needs and performance needs. You are
> correct that general read() and write() operations are not audited,
> and generally not checked from a LSM perspective as the auditing and
> access control happens at open() time instead (access to fds is
> revalidated when they are passed). However, in the case of getxattr
> and fgetxattr, these are not normal file read operations, and do not
> go through the same code path in the kernel; there is a reason why we
> have xattr_permission() and security_inode_getxattr().
>
> We need to continue to audit IORING_OP_FGETXATTR and IORING_OP_GETXATTR.
Fair enough. This would be similar reasoning to send/recv vs
sendmsg/recvmsg. I'll drop this patch. Thanks for the reasoning and
feedback.
> paul-moore.com
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
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
On 2023-01-27 16:03, Jens Axboe wrote:
> On 1/27/23 4:02 PM, Richard Guy Briggs wrote:
> > On 2023-01-27 15:45, 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? 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.
> >
> > That was one suspicion I had. If this is the case, I'd agree both could
> > be skipped.
>
> I'd be surprised if Steve didn't mix them up. Once he responds, can you
> send a v2 with the correction?
Gladly.
> Jens Axboe
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
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
On 2023-01-27 16:02, Jens Axboe wrote: > On 1/27/23 3:53 PM, Paul Moore wrote: > > On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe wrote: > >> On 1/27/23 3:38 PM, Paul Moore wrote: > >>> On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe wrote: > >>>> On 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. > > Sure, but then it should be open. Or do separate postings or something. > CC'ing a closed list with open lists and sending email to people that > are not on that closed list is bad form. I've made an inquiry. > Jens Axboe - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- 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
On 2023-01-27 15:45, 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? 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.
That was one suspicion I had. If this is the case, I'd agree both could
be skipped.
> Jens Axboe
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
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
On 2023-01-27 17:43, Paul Moore wrote:
> On Fri, Jan 27, 2023 at 12:24 PM Richard Guy Briggs wrote:
> > Getting XATTRs is not particularly interesting security-wise.
> >
> > Suggested-by: 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_classes_permissions.md#common-file-permissions
The intent here is to lessen the impact of audit operations. Read and
Write were explicitly removed from io_uring auditing due to performance
concerns coupled with the denial of service implications from sheer
volume of records making other messages harder to locate. Those
operations are still possible for syscall auditing but they are strongly
discouraged for normal use.
If the frequency of getxattr io_uring ops is so infrequent as to be no
distraction, then this patch may be more of a liability than a benefit.
> > diff --git a/io_uring/opdef.c b/io_uring/opdef.c
> > index a2bf53b4a38a..f6bfe2cf078c 100644
> > --- a/io_uring/opdef.c
> > +++ b/io_uring/opdef.c
> > @@ -462,12 +462,14 @@ const struct io_op_def io_op_defs[] = {
> > },
> > [IORING_OP_FGETXATTR] = {
> > .needs_file = 1,
> > + .audit_skip = 1,
> > .name = "FGETXATTR",
> > .prep = io_fgetxattr_prep,
> > .issue = io_fgetxattr,
> > .cleanup= io_xattr_cleanup,
> > },
> > [IORING_OP_GETXATTR] = {
> > + .audit_skip = 1,
> > .name = "GETXATTR",
> > .prep = io_getxattr_prep,
> > .issue = io_getxattr,
> > --
> > 2.27.0
>
> --
> paul-moore.com
>
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
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
On 2023-01-27 17:35, Paul Moore wrote:
> On Fri, Jan 27, 2023 at 12:24 PM Richard Guy Briggs wrote:
> >
> > Since FADVISE can truncate files and MADVISE operates on memory, reverse
> > 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?
I don't know. I was going on the advice of Steve Grubb. I'm looking
for feedback, validation, correction, here.
> > [IORING_OP_MADVISE] = {
> > + .audit_skip = 1,
> > .name = "MADVISE",
> > .prep = io_madvise_prep,
> > .issue = io_madvise,
>
> I *think* this should be okay, what testing/verification have you done
> on this? One of the things I like to check is to see if any LSMs
> might perform an access check and/or generate an audit record on an
> operation, if there is a case where that could happen we should setup
> audit properly. I did a very quick check of do_madvise() and nothing
> jumped out at me, but I would be interested in knowing what testing or
> verification you did here.
No testing other than build/boot/audit-testsuite. You had a test you
had developed that went through several iterations?
> paul-moore.com
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v1 2/2] io_uring,audit: do not log IORING_OP_*GETXATTR
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(+)
diff --git a/io_uring/opdef.c b/io_uring/opdef.c
index a2bf53b4a38a..f6bfe2cf078c 100644
--- a/io_uring/opdef.c
+++ b/io_uring/opdef.c
@@ -462,12 +462,14 @@ const struct io_op_def io_op_defs[] = {
},
[IORING_OP_FGETXATTR] = {
.needs_file = 1,
+ .audit_skip = 1,
.name = "FGETXATTR",
.prep = io_fgetxattr_prep,
.issue = io_fgetxattr,
.cleanup= io_xattr_cleanup,
},
[IORING_OP_GETXATTR] = {
+ .audit_skip = 1,
.name = "GETXATTR",
.prep = io_getxattr_prep,
.issue = io_getxattr,
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v1 0/2] two suggested iouring op audit updates
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(-) -- 2.27.0 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v1 1/2] io_uring, audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE
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,
},
[IORING_OP_MADVISE] = {
+ .audit_skip = 1,
.name = "MADVISE",
.prep = io_madvise_prep,
.issue = io_madvise,
--
2.27.0
--
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
On 2023-01-20 13:58, Paul Moore wrote:
> On Tue, Jan 17, 2023 at 4:14 PM Richard Guy Briggs wrote:
> >
> > This patch passes the full response so that the audit function can use all
> > 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/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;
> > + }
> > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > + "resp=%u fan_type=%u fan_info=%X subj_trust=%u
> > obj_trust=%u",
> > + response, friar->hdr.type, friar->rule_number,
> > + friar->subj_trust, friar->obj_trust);
> > }
>
> The only thing that comes to mind might be to convert the if-return
> into a switch statement to make it a bit cleaner and easier to patch
> in the future, but that is s far removed from any real concern
> that I debated even mentioning it. I only bring it up in case the
> "3F" discussion results in a respin, and even then I'm not going to
> hold my ACK over something as silly as a if-return vs switch.
>
> For clarity, this is what I was thinking:
>
> void __audit_fanontify(...)
> {
> switch (type) {
> case FAN_RESPONSE_INFO_NONE:
> audit_log(...);
> break;
> default:
> audit_log(...);
> }
> }
I agree that would be cleaner, but FAN_RESPONSE_INFO_NONE and
FAN_RESPONSE_INFO_AUDIT_RULE would be the two, with default being
ignored since they could be other types unrelated to audit.
There were a number of bits of code to future proof it in previous
versions that were questioned as necessary so they were removed...
> paul-moore.com
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
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
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"
> 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.
> paul-moore.com
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v6 2/3] fanotify: define struct members to hold response decision context
This patch adds a flag, FAN_INFO and an extensible buffer to provide
additional information about response decisions. The buffer contains
one or more headers defining the information type and the length of the
following information. The patch defines one additional information
type, FAN_RESPONSE_INFO_AUDIT_RULE, to audit a rule number. This will
allow for the creation of other information types in the future if other
users of the API identify different needs.
The kernel can be tested if it supports a given info type by supplying
the complete info extension but setting fd to FAN_NOFD. It will return
the expected size but not issue an audit record.
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
Suggested-by: Jan Kara
Link: https://lore.kernel.org/r/20201001101219.ge17...@quack2.suse.cz
Signed-off-by: Richard Guy Briggs
---
fs/notify/fanotify/fanotify.c | 5 +-
fs/notify/fanotify/fanotify.h | 4 ++
fs/notify/fanotify/fanotify_user.c | 86 ++
include/linux/fanotify.h | 5 ++
include/uapi/linux/fanotify.h | 30 ++-
5 files changed, 107 insertions(+), 23 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index a2a15bc4df28..24ec1d66d5a8 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -262,7 +262,7 @@ static int fanotify_get_response(struct fsnotify_group
*group,
}
/* userspace responded, convert to something usable */
- switch (event->response & ~FAN_AUDIT) {
+ switch (event->response & FANOTIFY_RESPONSE_ACCESS) {
case FAN_ALLOW:
ret = 0;
break;
@@ -563,6 +563,9 @@ static struct fanotify_event
*fanotify_alloc_perm_event(const struct path *path,
pevent->fae.type = FANOTIFY_EVENT_TYPE_PATH_PERM;
pevent->response = 0;
+ pevent->hdr.type = FAN_RESPONSE_INFO_NONE;
+ pevent->hdr.pad = 0;
+ pevent->hdr.len = 0;
pevent->state = FAN_EVENT_INIT;
pevent->path = *path;
path_get(path);
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index f899d610bc08..e8a3c28c5d12 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -428,6 +428,10 @@ struct fanotify_perm_event {
u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
+ union {
+ struct fanotify_response_info_header hdr;
+ struct fanotify_response_info_audit_rule audit_rule;
+ };
};
static inline struct fanotify_perm_event *
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index caa1211bac8c..8f430bfad487 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -283,19 +283,42 @@ static int create_fd(struct fsnotify_group *group, const
struct path *path,
return client_fd;
}
+static int process_access_response_info(const char __user *info,
+ size_t info_len,
+ struct fanotify_response_info_audit_rule *friar)
+{
+ if (info_len != sizeof(*friar))
+ return -EINVAL;
+
+ if (copy_from_user(friar, info, sizeof(*friar)))
+ return -EFAULT;
+
+ if (friar->hdr.type != FAN_RESPONSE_INFO_AUDIT_RULE)
+ return -EINVAL;
+ if (friar->hdr.pad != 0)
+ return -EINVAL;
+ if (friar->hdr.len != sizeof(*friar))
+ return -EINVAL;
+
+ return info_len;
+}
+
/*
* Finish processing of permission event by setting it to ANSWERED state and
* drop group->notification_lock.
*/
static void finish_permission_event(struct fsnotify_group *group,
- struct fanotify_perm_event *event,
- u32 response)
+ struct fanotify_perm_event *event, u32
response,
+ struct fanotify_response_info_audit_rule
*friar)
__releases(>notification_lock)
{
bool destroy = false;
assert_spin_locked(>notification_lock);
- event->response = response;
+ event->response = response & ~FAN_INFO;
+ if (response & FAN_INFO)
+ memcpy(>audit_rule, friar, sizeof(*friar));
+
if (event->state == FAN_EVENT_CANCELED)
destroy = true;
else
@@ -306,20 +329,27 @@ static void finish_permission_event(struct fsnotify_group
*group,
}
static int process_access_response(struct fsnotify_group *group,
- struct fanotify_response *response_struct)
+
[PATCH v6 1/3] fanotify: Ensure consistent variable type for response
The user space API for the response variable is __u32. This patch makes
sure that the whole path through the kernel uses u32 so that there is
no sign extension or truncation of the user space response.
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/12617626.uLZWGnKmhe@x2
Signed-off-by: Richard Guy Briggs
Acked-by: Paul Moore
---
fs/notify/fanotify/fanotify.h | 2 +-
fs/notify/fanotify/fanotify_user.c | 6 +++---
include/linux/audit.h | 6 +++---
kernel/auditsc.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index 57f51a9a3015..f899d610bc08 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -425,7 +425,7 @@ FANOTIFY_PE(struct fanotify_event *event)
struct fanotify_perm_event {
struct fanotify_event fae;
struct path path;
- unsigned short response;/* userspace answer to the event */
+ u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
};
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index 4546da4a54f9..caa1211bac8c 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -289,7 +289,7 @@ static int create_fd(struct fsnotify_group *group, const
struct path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- unsigned int response)
+ u32 response)
__releases(>notification_lock)
{
bool destroy = false;
@@ -310,9 +310,9 @@ static int process_access_response(struct fsnotify_group
*group,
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
- int response = response_struct->response;
+ u32 response = response_struct->response;
- pr_debug("%s: group=%p fd=%d response=%d\n", __func__, group,
+ pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
fd, response);
/*
* make sure the response is valid, if invalid we do nothing and either
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 3608992848d3..d6b7d0c7ce43 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -416,7 +416,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(unsigned int response);
+extern void __audit_fanotify(u32 response);
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,7 +523,7 @@ static inline void audit_log_kern_module(char *name)
__audit_log_kern_module(name);
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{
if (!audit_dummy_context())
__audit_fanotify(response);
@@ -679,7 +679,7 @@ static inline void audit_log_kern_module(char *name)
{
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{ }
static inline void audit_tk_injoffset(struct timespec64 offset)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 547c88be8a28..d1fb821de104 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2877,7 +2877,7 @@ void __audit_log_kern_module(char *name)
context->type = AUDIT_KERN_MODULE;
}
-void __audit_fanotify(unsigned int response)
+void __audit_fanotify(u32 response)
{
audit_log(audit_context(), GFP_KERNEL,
AUDIT_FANOTIFY, "resp=%u", response);
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v6 3/3] fanotify, audit: Allow audit to use the full permission event response
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,
+ "resp=%u fan_type=%u fan_info=3F subj_trust=2
obj_trust=2",
+ response, FAN_RESPONSE_INFO_NONE);
+ return;
+ }
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=%u fan_info=%X subj_trust=%u obj_trust=%u",
+ response, friar->hdr.type, friar->rule_number,
+ friar->subj_trust, friar->obj_trust);
}
void __audit_tk_injoffset(struct timespec64 offset)
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v6 0/3] fanotify: Allow user space to pass back additional audit info
() on FAN_NOFD after process_access_response_info() Link: https://lore.kernel.org/all/cover.1673989212.git@redhat.com Richard Guy Briggs (3): fanotify: Ensure consistent variable type for response fanotify: define struct members to hold response decision context fanotify,audit: Allow audit to use the full permission event response fs/notify/fanotify/fanotify.c | 8 ++- fs/notify/fanotify/fanotify.h | 6 +- fs/notify/fanotify/fanotify_user.c | 88 ++ include/linux/audit.h | 9 +-- include/linux/fanotify.h | 5 ++ include/uapi/linux/fanotify.h | 30 +- kernel/auditsc.c | 16 +- 7 files changed, 129 insertions(+), 33 deletions(-) -- 2.27.0 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v5 2/3] fanotify: define struct members to hold response decision context
On 2023-01-17 09:27, Jan Kara wrote:
> On Mon 16-01-23 15:42:29, Richard Guy Briggs wrote:
> > On 2023-01-03 13:42, Jan Kara wrote:
> > > On Thu 22-12-22 15:47:21, Richard Guy Briggs wrote:
> > > > > > +
> > > > > > + if (info_len != sizeof(*friar))
> > > > > > + return -EINVAL;
> > > > > > +
> > > > > > + if (copy_from_user(friar, info, sizeof(*friar)))
> > > > > > + return -EFAULT;
> > > > > > +
> > > > > > + if (friar->hdr.type != FAN_RESPONSE_INFO_AUDIT_RULE)
> > > > > > + return -EINVAL;
> > > > > > + if (friar->hdr.pad != 0)
> > > > > > + return -EINVAL;
> > > > > > + if (friar->hdr.len != sizeof(*friar))
> > > > > > + return -EINVAL;
> > > > > > +
> > > > > > + return info_len;
> > > > > > +}
> > > > > > +
> > > > >
> > > > > ...
> > > > >
> > > > > > @@ -327,10 +359,18 @@ static int process_access_response(struct
> > > > > > fsnotify_group *group,
> > > > > > return -EINVAL;
> > > > > > }
> > > > > >
> > > > > > - if (fd < 0)
> > > > > > + if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group,
> > > > > > FAN_ENABLE_AUDIT))
> > > > > > return -EINVAL;
> > > > > >
> > > > > > - if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group,
> > > > > > FAN_ENABLE_AUDIT))
> > > > > > + if (response & FAN_INFO) {
> > > > > > + ret = process_access_response_info(fd, info, info_len,
> > > > > > );
> > > > > > + if (ret < 0)
> > > > > > + return ret;
> > > > > > + } else {
> > > > > > + ret = 0;
> > > > > > + }
> > > > > > +
> > > > > > + if (fd < 0)
> > > > > > return -EINVAL;
> > > > >
> > > > > And here I'd do:
> > > > >
> > > > > if (fd == FAN_NOFD)
> > > > > return 0;
> > > > > if (fd < 0)
> > > > > return -EINVAL;
> > > > >
> > > > > As we talked in previous revisions we'd specialcase FAN_NOFD to just
> > > > > verify
> > > > > extra info is understood by the kernel so that application writing
> > > > > fanotify
> > > > > responses has a way to check which information it can provide to the
> > > > > kernel.
> > > >
> > > > The reason for including it in process_access_response_info() is to make
> > > > sure that it is included in the FAN_INFO case to detect this extension.
> > > > If it were included here
> > >
> > > I see what you're getting at now. So the condition
> > >
> > > if (fd == FAN_NOFD)
> > > return 0;
> > >
> > > needs to be moved into
> > >
> > > if (response & FAN_INFO)
> > >
> > > branch after process_access_response_info(). I still prefer to keep it
> > > outside of the process_access_response_info() function itself as it looks
> > > more logical to me. Does it address your concerns?
> >
> > Ok. Note that this does not return zero to userspace, since this
> > function's return value is added to the size of the struct
> > fanotify_response when there is no error.
>
> Right, good point. 0 is not a good return value in this case.
>
> > For that reason, I think it makes more sense to return -ENOENT, or some
> > other unused error code that fits, unless you think it is acceptable to
> > return sizeof(struct fanotify_response) when FAN_INFO is set to indicate
> > this.
>
> Yeah, my intention was to indicate "success" to userspace so I'd like to
> return whatever we return for the case when struct fanotify_response is
> accepted for a normal file descriptor - looks like info_len is the right
> value. Thanks!
Ok, I hadn't thought of that. So, to confirm, when FAN_INFO is set, if
FAN_NOFD is also set, return info_len from process_access_response() and
then immediately return sizeof(struct fanotify_response) plus info_len
to userspace without issuing an audit record should indicate support for
FAN_INFO and the specific info type supplied.
Thanks for helping work through this.
> Honza
> --
> Jan Kara
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v5 2/3] fanotify: define struct members to hold response decision context
On 2023-01-03 13:42, Jan Kara wrote:
> On Thu 22-12-22 15:47:21, Richard Guy Briggs wrote:
> > On 2022-12-16 17:43, Jan Kara wrote:
> > > On Mon 12-12-22 09:06:10, Richard Guy Briggs wrote:
> > > > This patch adds a flag, FAN_INFO and an extensible buffer to provide
> > > > additional information about response decisions. The buffer contains
> > > > one or more headers defining the information type and the length of the
> > > > following information. The patch defines one additional information
> > > > type, FAN_RESPONSE_INFO_AUDIT_RULE, to audit a rule number. This will
> > > > allow for the creation of other information types in the future if other
> > > > users of the API identify different needs.
> > > >
> > > > Suggested-by: Steve Grubb
> > > > Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> > > > Suggested-by: Jan Kara
> > > > Link: https://lore.kernel.org/r/20201001101219.ge17...@quack2.suse.cz
> > > > Signed-off-by: Richard Guy Briggs
> > > > +{
> > > > + if (fd == FAN_NOFD)
> > > > + return -ENOENT;
> > >
> > > I would not test 'fd' in this function at all. After all it is not part of
> > > the response info structure and you do check it in
> > > process_access_response() anyway.
> >
> > I wrestled with that. I was even tempted to swallow the following fd
> > check too, but the flow would not have made as much sense for the
> > non-INFO case.
> >
> > My understanding from Amir was that FAN_NOFD was only to be sent in in
> > conjuction with FAN_INFO to test if a newer kernel was present.
>
> Yes, that is correct. But we not only want to check that FAN_INFO flag is
> understood (as you do in your patch) but also whether a particular response
> type is understood (which you don't verify for FAN_NOFD). Currently, there
> is only one response type (FAN_RESPONSE_INFO_AUDIT_RULE) but if there are
> more in the future we need old kernels to refuse new response types even
> for FAN_NOFD case.
Ok, I agree the NOFD check should be after.
> > I presumed that if FAN_NOFD was present without FAN_INFO that was an
> > invalid input to an old kernel.
>
> Yes, that is correct and I agree the conditions I've suggested below are
> wrong in that regard and need a bit of tweaking. Thanks for catching it.
>
> > > > +
> > > > + if (info_len != sizeof(*friar))
> > > > + return -EINVAL;
> > > > +
> > > > + if (copy_from_user(friar, info, sizeof(*friar)))
> > > > + return -EFAULT;
> > > > +
> > > > + if (friar->hdr.type != FAN_RESPONSE_INFO_AUDIT_RULE)
> > > > + return -EINVAL;
> > > > + if (friar->hdr.pad != 0)
> > > > + return -EINVAL;
> > > > + if (friar->hdr.len != sizeof(*friar))
> > > > + return -EINVAL;
> > > > +
> > > > + return info_len;
> > > > +}
> > > > +
> > >
> > > ...
> > >
> > > > @@ -327,10 +359,18 @@ static int process_access_response(struct
> > > > fsnotify_group *group,
> > > > return -EINVAL;
> > > > }
> > > >
> > > > - if (fd < 0)
> > > > + if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group,
> > > > FAN_ENABLE_AUDIT))
> > > > return -EINVAL;
> > > >
> > > > - if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group,
> > > > FAN_ENABLE_AUDIT))
> > > > + if (response & FAN_INFO) {
> > > > + ret = process_access_response_info(fd, info, info_len,
> > > > );
> > > > + if (ret < 0)
> > > > + return ret;
> > > > + } else {
> > > > + ret = 0;
> > > > + }
> > > > +
> > > > + if (fd < 0)
> > > > return -EINVAL;
> > >
> > > And here I'd do:
> > >
> > > if (fd == FAN_NOFD)
> > > return 0;
> > > if (fd < 0)
> > > return -EINVAL;
> > >
> > > As we talked in previous revisions we'd specialcase FAN_NOFD to just
> > > verify
> > > extra info is understood by the kernel so that application writing
>
Re: [PATCH v5 3/3] fanotify, audit: Allow audit to use the full permission event response
On 2023-01-10 10:26, Steve Grubb wrote: > 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. Ah good, thank you. > -Steve - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- 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
On 2023-01-09 19:06, Steve Grubb wrote:
> 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.
I'll have a closer look, because this wasn't the intended behaviour.
> 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...
Well, it *is* 13 decimal, expressed as a hex-encoded string as was
requested for future-proofing, albeit longer than necessary...
> > 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 voi
Re: New bug in Audit
On 2023-01-05 11:31, Steve Grubb wrote: > On Thursday, January 5, 2023 10:41:49 AM EST Paul Moore wrote: > > On Thu, Jan 5, 2023 at 8:38 AM Ariel Silver wrote: > > > I found the following bug: > > > > > > OS version = Red Hat Enterprise Linux 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. We did, it is filed upstream as: https://github.com/linux-audit/audit-kernel/issues/138 > > 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 Yes, that commit fixes that bug upstream. It has been backported to RHEL. > -Steve - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v5 2/3] fanotify: define struct members to hold response decision context
On 2022-12-16 17:43, Jan Kara wrote:
> On Mon 12-12-22 09:06:10, Richard Guy Briggs wrote:
> > This patch adds a flag, FAN_INFO and an extensible buffer to provide
> > additional information about response decisions. The buffer contains
> > one or more headers defining the information type and the length of the
> > following information. The patch defines one additional information
> > type, FAN_RESPONSE_INFO_AUDIT_RULE, to audit a rule number. This will
> > allow for the creation of other information types in the future if other
> > users of the API identify different needs.
> >
> > Suggested-by: Steve Grubb
> > Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> > Suggested-by: Jan Kara
> > Link: https://lore.kernel.org/r/20201001101219.ge17...@quack2.suse.cz
> > Signed-off-by: Richard Guy Briggs
>
> Thanks for the patches. They look very good to me. Just two nits below. I
> can do the small updates on commit if there would be no other changes. But
> I'd like to get some review from audit guys for patch 3/3 before I commit
> this.
I'd prefer to send a followup patch based on your recommendations rather
than have you modify it. It does save some back and forth though...
> > diff --git a/fs/notify/fanotify/fanotify_user.c
> > b/fs/notify/fanotify/fanotify_user.c
> > index caa1211bac8c..cf3584351e00 100644
> > --- a/fs/notify/fanotify/fanotify_user.c
> > +++ b/fs/notify/fanotify/fanotify_user.c
> > @@ -283,19 +283,44 @@ static int create_fd(struct fsnotify_group *group,
> > const struct path *path,
> > return client_fd;
> > }
> >
> > +static int process_access_response_info(int fd, const char __user *info,
> > size_t info_len,
> > + struct
> > fanotify_response_info_audit_rule *friar)
>
> I prefer to keep lines within 80 columns, unless there is really good
> reason (like with strings) to have them longer.
Sure. In this case, it buys us little since the last line is lined up
with the arguments openning bracket and it one long struct name unless I
unalign that argument and back up the indent by one.
> BTW, why do you call the info structure 'friar'? I feel some language twist
> escapes me ;)
Fanotify_Response_Info_Audit_Rule, it is a pronounceable word, and
besides they have a long reputation for making good beer. :-D
> > +{
> > + if (fd == FAN_NOFD)
> > + return -ENOENT;
>
> I would not test 'fd' in this function at all. After all it is not part of
> the response info structure and you do check it in
> process_access_response() anyway.
I wrestled with that. I was even tempted to swallow the following fd
check too, but the flow would not have made as much sense for the
non-INFO case.
My understanding from Amir was that FAN_NOFD was only to be sent in in
conjuction with FAN_INFO to test if a newer kernel was present.
I presumed that if FAN_NOFD was present without FAN_INFO that was an
invalid input to an old kernel.
> > +
> > + if (info_len != sizeof(*friar))
> > + return -EINVAL;
> > +
> > + if (copy_from_user(friar, info, sizeof(*friar)))
> > + return -EFAULT;
> > +
> > + if (friar->hdr.type != FAN_RESPONSE_INFO_AUDIT_RULE)
> > + return -EINVAL;
> > + if (friar->hdr.pad != 0)
> > + return -EINVAL;
> > + if (friar->hdr.len != sizeof(*friar))
> > + return -EINVAL;
> > +
> > + return info_len;
> > +}
> > +
>
> ...
>
> > @@ -327,10 +359,18 @@ static int process_access_response(struct
> > fsnotify_group *group,
> > return -EINVAL;
> > }
> >
> > - if (fd < 0)
> > + if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> > return -EINVAL;
> >
> > - if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> > + if (response & FAN_INFO) {
> > + ret = process_access_response_info(fd, info, info_len, );
> > + if (ret < 0)
> > + return ret;
> > + } else {
> > + ret = 0;
> > + }
> > +
> > + if (fd < 0)
> > return -EINVAL;
>
> And here I'd do:
>
> if (fd == FAN_NOFD)
> return 0;
> if (fd < 0)
> return -EINVAL;
>
> As we talked in previous revisions we'd specialcase FAN_NOFD to just verify
> extra info is understood by the kernel so that application writing fanotify
> responses has a way to check which information it can provide to the
> kernel.
The reason for i
Re: [PATCH v5 3/3] fanotify,audit: Allow audit to use the full permission event response
On 2022-12-20 18:31, Paul Moore wrote:
> On Mon, Dec 12, 2022 at 9:06 AM 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 .
> >
> > 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/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 __audit_fanotify(u32 response, struct
> > fanotify_response_info_audit_rule *friar)
> > {
> > - audit_log(audit_context(), GFP_KERNEL,
> > - AUDIT_FANOTIFY, "resp=%u", response);
> > + struct audit_context *ctx = audit_context();
> > + struct audit_buffer *ab;
> > + char numbuf[12];
> > +
> > + 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);
>
> The fan_info, subj_trust, and obj_trust constant values used here are
> awfully magic-numbery and not the usual sentinel values one might
> expect for a "none" operation, e.g. zeros/INT_MAX/etc. I believe a
> comment here explaining the values would be a good idea.
Ack. I'll add a comment. I would have preferred zero for default of
unset, but Steve requested 0/1/2 no/yes/unknown.
> > + return;
> > + }
> > + 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);
> > + snprintf(numbuf, sizeof(numbuf), "%u", friar->rule_number);
> > + audit_log_n_hex(ab, numbuf, sizeof(numbuf));
>
> It looks like the kernel's printf format string parsing supports %X so
> why not just use that for now, we can always complicate it later if
> needed. It would probably also remove the need for the @ab, @numbuf,
> and @ctx variables. For example:
>
> audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> "resp=%u fan_type=%u fan_info=%X subj_trust=%u obj_trust=%u",
> response, friar->hdr.type, friar->rule_number,
> friar->subj_trust, friar->obj_trust);
>
> Am I missing something?
No, I am. Thank you, that's much cleaner.
> > + audit_log_format(ab, " subj_trust=%u obj_trust=%u",
> > +friar->subj_trust, friar->obj_trust);
> > + audit_log_end(ab);
> > + }
> > }
> >
> > void __audit_tk_injoffset(struct timespec64 offset)
> > --
> > 2.27.0
>
> --
> paul-moore.com
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://listman.redhat.com/mailman/listinfo/linux-audit
>
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v5 3/3] fanotify, audit: Allow audit to use the full permission event response
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 .
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 __audit_fanotify(u32 response, struct fanotify_response_info_audit_rule
*friar)
{
- audit_log(audit_context(), GFP_KERNEL,
- AUDIT_FANOTIFY, "resp=%u", response);
+ struct audit_context *ctx = audit_context();
+ struct audit_buffer *ab;
+ char numbuf[12];
+
+ 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;
+ }
+ 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);
+ snprintf(numbuf, sizeof(numbuf), "%u", friar->rule_number);
+ audit_log_n_hex(ab, numbuf, sizeof(numbuf));
+ audit_log_format(ab, " subj_trust=%u obj_trust=%u",
+friar->subj_trust, friar->obj_trust);
+ audit_log_end(ab);
+ }
}
void __audit_tk_injoffset(struct timespec64 offset)
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v5 2/3] fanotify: define struct members to hold response decision context
This patch adds a flag, FAN_INFO and an extensible buffer to provide
additional information about response decisions. The buffer contains
one or more headers defining the information type and the length of the
following information. The patch defines one additional information
type, FAN_RESPONSE_INFO_AUDIT_RULE, to audit a rule number. This will
allow for the creation of other information types in the future if other
users of the API identify different needs.
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
Suggested-by: Jan Kara
Link: https://lore.kernel.org/r/20201001101219.ge17...@quack2.suse.cz
Signed-off-by: Richard Guy Briggs
---
fs/notify/fanotify/fanotify.c | 5 +-
fs/notify/fanotify/fanotify.h | 4 ++
fs/notify/fanotify/fanotify_user.c | 86 ++
include/linux/fanotify.h | 5 ++
include/uapi/linux/fanotify.h | 30 ++-
5 files changed, 107 insertions(+), 23 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index a2a15bc4df28..24ec1d66d5a8 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -262,7 +262,7 @@ static int fanotify_get_response(struct fsnotify_group
*group,
}
/* userspace responded, convert to something usable */
- switch (event->response & ~FAN_AUDIT) {
+ switch (event->response & FANOTIFY_RESPONSE_ACCESS) {
case FAN_ALLOW:
ret = 0;
break;
@@ -563,6 +563,9 @@ static struct fanotify_event
*fanotify_alloc_perm_event(const struct path *path,
pevent->fae.type = FANOTIFY_EVENT_TYPE_PATH_PERM;
pevent->response = 0;
+ pevent->hdr.type = FAN_RESPONSE_INFO_NONE;
+ pevent->hdr.pad = 0;
+ pevent->hdr.len = 0;
pevent->state = FAN_EVENT_INIT;
pevent->path = *path;
path_get(path);
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index f899d610bc08..e8a3c28c5d12 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -428,6 +428,10 @@ struct fanotify_perm_event {
u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
+ union {
+ struct fanotify_response_info_header hdr;
+ struct fanotify_response_info_audit_rule audit_rule;
+ };
};
static inline struct fanotify_perm_event *
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index caa1211bac8c..cf3584351e00 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -283,19 +283,44 @@ static int create_fd(struct fsnotify_group *group, const
struct path *path,
return client_fd;
}
+static int process_access_response_info(int fd, const char __user *info,
size_t info_len,
+ struct
fanotify_response_info_audit_rule *friar)
+{
+ if (fd == FAN_NOFD)
+ return -ENOENT;
+
+ if (info_len != sizeof(*friar))
+ return -EINVAL;
+
+ if (copy_from_user(friar, info, sizeof(*friar)))
+ return -EFAULT;
+
+ if (friar->hdr.type != FAN_RESPONSE_INFO_AUDIT_RULE)
+ return -EINVAL;
+ if (friar->hdr.pad != 0)
+ return -EINVAL;
+ if (friar->hdr.len != sizeof(*friar))
+ return -EINVAL;
+
+ return info_len;
+}
+
/*
* Finish processing of permission event by setting it to ANSWERED state and
* drop group->notification_lock.
*/
static void finish_permission_event(struct fsnotify_group *group,
- struct fanotify_perm_event *event,
- u32 response)
+ struct fanotify_perm_event *event, u32
response,
+ struct fanotify_response_info_audit_rule
*friar)
__releases(>notification_lock)
{
bool destroy = false;
assert_spin_locked(>notification_lock);
- event->response = response;
+ event->response = response & ~FAN_INFO;
+ if (response & FAN_INFO)
+ memcpy(>audit_rule, friar, sizeof(*friar));
+
if (event->state == FAN_EVENT_CANCELED)
destroy = true;
else
@@ -306,20 +331,27 @@ static void finish_permission_event(struct fsnotify_group
*group,
}
static int process_access_response(struct fsnotify_group *group,
- struct fanotify_response *response_struct)
+ struct fanotify_response *response_struct,
+ const char __user *info,
+ size_t info_len)
{
[PATCH v5 1/3] fanotify: Ensure consistent variable type for response
The user space API for the response variable is __u32. This patch makes
sure that the whole path through the kernel uses u32 so that there is
no sign extension or truncation of the user space response.
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/12617626.uLZWGnKmhe@x2
Signed-off-by: Richard Guy Briggs
---
fs/notify/fanotify/fanotify.h | 2 +-
fs/notify/fanotify/fanotify_user.c | 6 +++---
include/linux/audit.h | 6 +++---
kernel/auditsc.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index 57f51a9a3015..f899d610bc08 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -425,7 +425,7 @@ FANOTIFY_PE(struct fanotify_event *event)
struct fanotify_perm_event {
struct fanotify_event fae;
struct path path;
- unsigned short response;/* userspace answer to the event */
+ u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
};
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index 4546da4a54f9..caa1211bac8c 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -289,7 +289,7 @@ static int create_fd(struct fsnotify_group *group, const
struct path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- unsigned int response)
+ u32 response)
__releases(>notification_lock)
{
bool destroy = false;
@@ -310,9 +310,9 @@ static int process_access_response(struct fsnotify_group
*group,
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
- int response = response_struct->response;
+ u32 response = response_struct->response;
- pr_debug("%s: group=%p fd=%d response=%d\n", __func__, group,
+ pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
fd, response);
/*
* make sure the response is valid, if invalid we do nothing and either
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 3608992848d3..d6b7d0c7ce43 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -416,7 +416,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(unsigned int response);
+extern void __audit_fanotify(u32 response);
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,7 +523,7 @@ static inline void audit_log_kern_module(char *name)
__audit_log_kern_module(name);
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{
if (!audit_dummy_context())
__audit_fanotify(response);
@@ -679,7 +679,7 @@ static inline void audit_log_kern_module(char *name)
{
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{ }
static inline void audit_tk_injoffset(struct timespec64 offset)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 547c88be8a28..d1fb821de104 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2877,7 +2877,7 @@ void __audit_log_kern_module(char *name)
context->type = AUDIT_KERN_MODULE;
}
-void __audit_fanotify(unsigned int response)
+void __audit_fanotify(u32 response)
{
audit_log(audit_context(), GFP_KERNEL,
AUDIT_FANOTIFY, "resp=%u", response);
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v5 0/3] fanotify: Allow user space to pass back additional audit info
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.
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=3F
subj_trust=? obj_trust=?
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 to u32
- assume and enforce one rule to audit, pass struct directly to
__audit_fanotify()
- change fanotify_perm_event struct to union hdr/audir_rule
- add vspace to fanotify_write() and process_access_response_info()
- squash 3/4 with 4/4
- fix v3 and v4 links
Link: https://lore.kernel.org/all/cover.1670606054.git@redhat.com
Richard Guy Briggs (3):
fanotify: Ensure consistent variable type for response
fanotify: define struct members to hold response decision context
fanotify,audit: Allow audit to use the full permission event response
fs/notify/fanotify/fanotify.c | 8 ++-
fs/notify/fanotify/fanotify.h | 6 +-
fs/notify/fanotify/fanotify_user.c | 88 ++
include/linux/audit.h | 9 +--
include/linux/fanotify.h
Re: [PATCH] audit: fix undefined behavior in bit shift for AUDIT_BIT
On 2022-10-31 07:34, Paul Moore wrote:
> On Sun, Oct 30, 2022 at 10:10 PM Gaosheng Cui wrote:
> >
> > Shifting signed 32-bit value by 31 bits is undefined, so changing
> > significant bit to unsigned. The UBSAN warning calltrace like below:
> >
> > UBSAN: shift-out-of-bounds in kernel/auditfilter.c:179:23
> > left shift of 1 by 31 places cannot be represented in type 'int'
> > Call Trace:
> >
> > dump_stack_lvl+0x7d/0xa5
> > dump_stack+0x15/0x1b
> > ubsan_epilogue+0xe/0x4e
> > __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
> > audit_register_class+0x9d/0x137
> > audit_classes_init+0x4d/0xb8
> > do_one_initcall+0x76/0x430
> > kernel_init_freeable+0x3b3/0x422
> > kernel_init+0x24/0x1e0
> > ret_from_fork+0x1f/0x30
> >
> >
> > Fixes: 607ca46e97a1 ("UAPI: (Scripted) Disintegrate include/linux")
>
> Thanks, this patch looks good, although the 'Fixes:' line above isn't
> correct. The commit you reference may be the commit which created
> AUDIT_BIT in include/uapi/linux/audit.h, but before that it was
> defined in include/linux/audit.h with the original implementation
> shipping in v2.6.6-rc1. As the original AUDIT_BIT implementation
> predates git itself, I would suggest removing the 'Fixes' line
> entirely and I'll simply add the usual stable marking when I merge it
> into audit/stable-6.1. If that is okay with you I'll go ahead and
> merge this patch which that tweak - is that okay?
In fact, it is the original kernel audit subsystem commit if you join
the 3 trees that went in to Linux 2.6.6-rc1:
commit b7b0074ca3c9fe22d07b97e42a99c8b27be6307f
Author: Andrew Morton
AuthorDate: 2004-04-11 23:29:12 -0700
Commit: Linus Torvalds
CommitDate: 2004-04-11 23:29:12 -0700
[PATCH] Light-weight Auditing Framework
From: Rik Faith
> > Signed-off-by: Gaosheng Cui
> > ---
> > include/uapi/linux/audit.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > index 7c1dc818b1d5..d676ed2b246e 100644
> > --- a/include/uapi/linux/audit.h
> > +++ b/include/uapi/linux/audit.h
> > @@ -187,7 +187,7 @@
> > #define AUDIT_MAX_KEY_LEN 256
> > #define AUDIT_BITMASK_SIZE 64
> > #define AUDIT_WORD(nr) ((__u32)((nr)/32))
> > -#define AUDIT_BIT(nr) (1 << ((nr) - AUDIT_WORD(nr)*32))
> > +#define AUDIT_BIT(nr) (1U << ((nr) - AUDIT_WORD(nr)*32))
> >
> > #define AUDIT_SYSCALL_CLASSES 16
> > #define AUDIT_CLASS_DIR_WRITE 0
> > --
> > 2.25.1
>
> --
> paul-moore.com
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://listman.redhat.com/mailman/listinfo/linux-audit
>
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
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
On 2022-09-09 10:55, Steve Grubb wrote: > 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. Ack. > -Steve - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- 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
On 2022-09-09 10:22, Steve Grubb wrote:
> 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.
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"?
> -Steve
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
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
On 2022-09-08 22:20, Steve Grubb wrote:
> 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.
So, "u32 trusted;" ? How would you like that formatted?
"fan_trust={0|1}"
> > 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?
> -Steve
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
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
On 2022-09-01 14:31, Paul Moore wrote:
> On Thu, Sep 1, 2022 at 3:52 AM Jan Kara wrote:
> > On Wed 31-08-22 21:47:09, Paul Moore wrote:
> > > On Wed, Aug 31, 2022 at 7:55 PM Steve Grubb wrote:
> > > > 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.
> &g
Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
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.
The need for more as yet undefined information sounds like a good reason
to define a new header if that happens.
At this point, is it reasonable to throw an error if more than one RULE
header appears in a message? 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.
How many rules total are likely to exist?
> -Steev
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
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
On 2022-08-15 20:22, Paul Moore wrote:
> On Tue, Aug 9, 2022 at 1:23 PM Richard Guy Briggs wrote:
> >
> > This patch passes the full value 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. The following is an example of the new record
> > format:
> >
> > type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=17
> >
> > 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 | 31 ---
> > 3 files changed, 35 insertions(+), 8 deletions(-)
>
> You've hopefully already seen the kernel test robot build warning, so
> I won't bring that up again, but a few comments below ...
Yes, dealt with...
...
> > 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?
> > + 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);
> > + return;
> > + }
> > + audit_log(audit_context(), GFP_KERNEL,
> > AUDIT_FANOTIFY,
> > + "resp=%u fan_type=%u fan_info=%u",
> > + response, friar->hdr.type,
> > friar->audit_rule);
> > + }
> > + c -= friar->hdr.len;
> > + ib += friar->hdr.len;
> > + }
> > }
> >
> > void __audit_tk_injoffset(struct timespec64 offset)
>
> paul-moore.com
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [RFC PATCH 2/2] fs/xattr: wire up syscalls
yscall.tbl > +++ b/arch/xtensa/kernel/syscalls/syscall.tbl > @@ -421,3 +421,7 @@ > 448 common process_mreleasesys_process_mrelease > 449 common futex_waitv sys_futex_waitv > 450 common set_mempolicy_home_node sys_set_mempolicy_home_node > +451 common setxattrat sys_setxattrat > +452 common getxattrat sys_getxattrat > +453 common listxattrat sys_listxattrat > +454 common removexattrat sys_removexattrat > diff --git a/include/asm-generic/audit_change_attr.h > b/include/asm-generic/audit_change_attr.h > index 331670807cf0..cc840537885f 100644 > --- a/include/asm-generic/audit_change_attr.h > +++ b/include/asm-generic/audit_change_attr.h > @@ -11,9 +11,15 @@ __NR_lchown, > __NR_fchown, > #endif > __NR_setxattr, > +#ifdef __NR_setxattrat > +__NR_setxattrat, > +#endif > __NR_lsetxattr, > __NR_fsetxattr, > __NR_removexattr, > +#ifdef __NR_removexattrat > +__NR_removexattrat, > +#endif > __NR_lremovexattr, > __NR_fremovexattr, > #ifdef __NR_fchownat > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h > index a34b0f9a9972..090b9b5229a0 100644 > --- a/include/linux/syscalls.h > +++ b/include/linux/syscalls.h > @@ -348,23 +348,31 @@ asmlinkage long sys_io_uring_register(unsigned int fd, > unsigned int op, > /* fs/xattr.c */ > asmlinkage long sys_setxattr(const char __user *path, const char __user > *name, >const void __user *value, size_t size, int flags); > +asmlinkage long sys_setxattrat(int dfd, const char __user *path, const char > __user *name, > + const void __user *value, size_t size, int flags); > asmlinkage long sys_lsetxattr(const char __user *path, const char __user > *name, > const void __user *value, size_t size, int flags); > asmlinkage long sys_fsetxattr(int fd, const char __user *name, > const void __user *value, size_t size, int flags); > asmlinkage long sys_getxattr(const char __user *path, const char __user > *name, >void __user *value, size_t size); > +asmlinkage long sys_getxattrat(int dfd, const char __user *path, const char > __user *name, > + void __user *value, size_t size, int flags); > asmlinkage long sys_lgetxattr(const char __user *path, const char __user > *name, > void __user *value, size_t size); > asmlinkage long sys_fgetxattr(int fd, const char __user *name, > void __user *value, size_t size); > asmlinkage long sys_listxattr(const char __user *path, char __user *list, > size_t size); > +asmlinkage long sys_listxattrat(int dfd, const char __user *path, char > __user *list, > + size_t size, int flags); > asmlinkage long sys_llistxattr(const char __user *path, char __user *list, > size_t size); > asmlinkage long sys_flistxattr(int fd, char __user *list, size_t size); > asmlinkage long sys_removexattr(const char __user *path, > const char __user *name); > +asmlinkage long sys_removexattrat(int dfd, const char __user *path, > + const char __user *name, int flags); > asmlinkage long sys_lremovexattr(const char __user *path, > const char __user *name); > asmlinkage long sys_fremovexattr(int fd, const char __user *name); > diff --git a/include/uapi/asm-generic/unistd.h > b/include/uapi/asm-generic/unistd.h > index 45fa180cc56a..4fcc71612b7a 100644 > --- a/include/uapi/asm-generic/unistd.h > +++ b/include/uapi/asm-generic/unistd.h > @@ -886,8 +886,18 @@ __SYSCALL(__NR_futex_waitv, sys_futex_waitv) > #define __NR_set_mempolicy_home_node 450 > __SYSCALL(__NR_set_mempolicy_home_node, sys_set_mempolicy_home_node) > > +/* fs/xattr.c */ > +#define __NR_setxattrat 451 > +__SYSCALL(__NR_setxattrat, sys_setxattrat) > +#define __NR_getxattrat 452 > +__SYSCALL(__NR_getxattrat, sys_getxattrat) > +#define __NR_listxattrat 453 > +__SYSCALL(__NR_listxattrat, sys_listxattrat) > +#define __NR_removexattrat 454 > +__SYSCALL(__NR_removexattrat, sys_removexattrat) > + > #undef __NR_syscalls > -#define __NR_syscalls 451 > +#define __NR_syscalls 455 > > /* > * 32 bit systems traditionally used different > -- > 2.37.2 > - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH] tests/io_uring: ensure that tne io_uring::enter_ring_fd is imported
On 2022-08-25 16:28, Paul Moore wrote:
> On Thu, Aug 25, 2022 at 4:10 PM Richard Guy Briggs wrote:
> > On 2022-08-24 15:42, Paul Moore wrote:
> > > The liburing library added a new field to the io_uring struct in
> > > commit b02125e164ea ("Add preliminary support for using a registered ring
> > > fd"),
> > > first seen in liburing v2.2.
> >
> > I'm guessing this should have been sent to the iouring folks?
>
> No, it's for the audit-testsuite. You'll find it committed as 9cf35a32dde4.
Oops! I was thinking this was for the kernel tree... Sorry for the
noise.
> > > Signed-off-by: Paul Moore
> > > ---
> > > tests/io_uring/iouring.c |1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/tests/io_uring/iouring.c b/tests/io_uring/iouring.c
> > > index 5d83146..af814f6 100644
> > > --- a/tests/io_uring/iouring.c
> > > +++ b/tests/io_uring/iouring.c
> > > @@ -233,6 +233,7 @@ int uring_import(int fd, struct io_uring *ring,
> > > struct io_uring_params *params)
> > > ring->flags = params->flags;
> > > ring->features = params->features;
> > > ring->ring_fd = fd;
> > > + ring->enter_ring_fd = fd;
> > >
> > > ring->sq.ring_sz = params->sq_off.array +
> > > params->sq_entries * sizeof(unsigned);
> > >
>
> --
> paul-moore.com
>
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH] tests/io_uring: ensure that tne io_uring::enter_ring_fd is imported
On 2022-08-24 15:42, Paul Moore wrote:
> The liburing library added a new field to the io_uring struct in
> commit b02125e164ea ("Add preliminary support for using a registered ring
> fd"),
> first seen in liburing v2.2.
I'm guessing this should have been sent to the iouring folks?
> Signed-off-by: Paul Moore
> ---
> tests/io_uring/iouring.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests/io_uring/iouring.c b/tests/io_uring/iouring.c
> index 5d83146..af814f6 100644
> --- a/tests/io_uring/iouring.c
> +++ b/tests/io_uring/iouring.c
> @@ -233,6 +233,7 @@ int uring_import(int fd, struct io_uring *ring, struct
> io_uring_params *params)
> ring->flags = params->flags;
> ring->features = params->features;
> ring->ring_fd = fd;
> + ring->enter_ring_fd = fd;
>
> ring->sq.ring_sz = params->sq_off.array +
> params->sq_entries * sizeof(unsigned);
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://listman.redhat.com/mailman/listinfo/linux-audit
>
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH ghak138 v2 2/4] audit: explicitly check audit_context->context enum value
Be explicit in checking the struct audit_context "context" member enum
value rather than assuming the order of context enum values.
Fixes: 12c5e81d3fd0 ("audit: prepare audit_context for use in calling contexts
beyond syscalls")
Signed-off-by: Richard Guy Briggs
---
kernel/auditsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 21e50e6d0fc0..d77c9805c6b1 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2068,7 +2068,7 @@ void __audit_syscall_exit(int success, long return_code)
/* run through both filters to ensure we set the filterkey properly */
audit_filter_syscall(current, context);
audit_filter_inodes(current, context);
- if (context->current_state < AUDIT_STATE_RECORD)
+ if (context->current_state != AUDIT_STATE_RECORD)
goto out;
audit_return_fixup(context, success, return_code);
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH ghak138 v2 1/4] audit: audit_context pid unused, context enum comment fix
The pid member of struct audit_context is never used. Remove it.
The audit_reset_context() comment about unconditionally resetting
"ctx->state" should read "ctx->context".
Signed-off-by: Richard Guy Briggs
---
kernel/audit.h | 2 +-
kernel/auditsc.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/audit.h b/kernel/audit.h
index 58b66543b4d5..d6eb7b59c791 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -133,7 +133,7 @@ struct audit_context {
struct sockaddr_storage *sockaddr;
size_t sockaddr_len;
/* Save things to print about task_struct */
- pid_t pid, ppid;
+ pid_t ppid;
kuid_t uid, euid, suid, fsuid;
kgid_t gid, egid, sgid, fsgid;
unsigned long personality;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 9226746dcf0a..21e50e6d0fc0 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -965,7 +965,7 @@ static void audit_reset_context(struct audit_context *ctx)
if (!ctx)
return;
- /* if ctx is non-null, reset the "ctx->state" regardless */
+ /* if ctx is non-null, reset the "ctx->context" regardless */
ctx->context = AUDIT_CTX_UNUSED;
if (ctx->dummy)
return;
@@ -1002,7 +1002,7 @@ static void audit_reset_context(struct audit_context *ctx)
kfree(ctx->sockaddr);
ctx->sockaddr = NULL;
ctx->sockaddr_len = 0;
- ctx->pid = ctx->ppid = 0;
+ ctx->ppid = 0;
ctx->uid = ctx->euid = ctx->suid = ctx->fsuid = KUIDT_INIT(0);
ctx->gid = ctx->egid = ctx->sgid = ctx->fsgid = KGIDT_INIT(0);
ctx->personality = 0;
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH ghak138 v2 4/4] audit: move audit_return_fixup before the filters
The success and return_code are needed by the filters. Move
audit_return_fixup() before the filters. This was causing syscall
auditing events to be missed.
Link: https://github.com/linux-audit/audit-kernel/issues/138
Fixes: 12c5e81d3fd0 ("audit: prepare audit_context for use in calling contexts
beyond syscalls")
Signed-off-by: Richard Guy Briggs
---
kernel/auditsc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 280b4720c7a0..9f8c05228d6d 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1940,6 +1940,7 @@ void __audit_uring_exit(int success, long code)
goto out;
}
+ audit_return_fixup(ctx, success, code);
if (ctx->context == AUDIT_CTX_SYSCALL) {
/*
* NOTE: See the note in __audit_uring_entry() about the case
@@ -1981,7 +1982,6 @@ void __audit_uring_exit(int success, long code)
audit_filter_inodes(current, ctx);
if (ctx->current_state != AUDIT_STATE_RECORD)
goto out;
- audit_return_fixup(ctx, success, code);
audit_log_exit();
out:
@@ -2065,13 +2065,13 @@ void __audit_syscall_exit(int success, long return_code)
if (!list_empty(>killed_trees))
audit_kill_trees(context);
+ audit_return_fixup(context, success, return_code);
/* run through both filters to ensure we set the filterkey properly */
audit_filter_syscall(current, context);
audit_filter_inodes(current, context);
if (context->current_state != AUDIT_STATE_RECORD)
goto out;
- audit_return_fixup(context, success, return_code);
audit_log_exit();
out:
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH ghak138 v2 3/4] audit: free audit_proctitle only on task exit
Since audit_proctitle is generated at syscall exit time, its value is
used immediately and cached for the next syscall. Since this is the
case, then only clear it at task exit time. Otherwise, there is no
point in caching the value OR bearing the overhead of regenerating it.
Fixes: 12c5e81d3fd0 ("audit: prepare audit_context for use in calling contexts
beyond syscalls")
Signed-off-by: Richard Guy Briggs
---
kernel/auditsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index d77c9805c6b1..280b4720c7a0 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1016,7 +1016,6 @@ static void audit_reset_context(struct audit_context *ctx)
WARN_ON(!list_empty(>killed_trees));
audit_free_module(ctx);
ctx->fds[0] = -1;
- audit_proctitle_free(ctx);
ctx->type = 0; /* reset last for audit_free_*() */
}
@@ -1077,6 +1076,7 @@ static inline void audit_free_context(struct
audit_context *context)
{
/* resetting is extra work, but it is likely just noise */
audit_reset_context(context);
+ audit_proctitle_free(context);
free_tree_refs(context);
kfree(context->filterkey);
kfree(context);
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH ghak138 v2 0/4] issues from moving beyond syscalls
The primary motivation was to solve the mystery of the missing syscall events filed in ghak138. This is addressed by the audit_return_fixup() patch and is most likely a stable candidate. The others were a number of not so critical issues observed in the process of examining the bisected patch to see what caused it. changelog v2: - split into 4 patches - flesh out proctitle move justification - add issue reference in return_fixup move patch - remove explicit Cc: Richard Guy Briggs (4): audit: audit_context pid unused, context enum comment fix audit: explicitly check audit_context->context enum value audit: free audit_proctitle only on task exit audit: move audit_return_fixup before the filters kernel/audit.h | 2 +- kernel/auditsc.c | 12 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) -- 2.27.0 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH ghak138] audit: move audit_return_fixup before the filters
On 2022-08-25 09:20, Paul Moore wrote:
> On Wed, Aug 24, 2022 at 11:10 PM Richard Guy Briggs wrote:
> >
> > The success and return_code are needed by the filters. Move
> > audit_return_fixup() before the filters.
> >
> > The pid member of struct audit_context is never used. Remove it.
> >
> > The audit_reset_context() comment about unconditionally resetting
> > "ctx->state" should read "ctx->context".
> >
> > The proctitle is intentionally stored between syscalls. Only free it in
> > audit_free_context().
> >
> > Be explicit in checking the struct audit_context "context" member enum
> > value rather than assuming the order of context enum values.
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: 12c5e81d3fd0 ("audit: prepare audit_context for use in calling
> > contexts beyond syscalls")
> > Signed-off-by: Richard Guy Briggs
> > ---
> > kernel/audit.h | 2 +-
> > kernel/auditsc.c | 12 ++--
> > 2 files changed, 7 insertions(+), 7 deletions(-)
>
> [NOTE: dropped the stable kernel alias from my reply]
NOTE: git send-patch must have added that since I only put it in the body.
> A couple of things:
>
> * I know you like to CC a lot of people on your patches Richard, but
> just a heads-up that you are likely to get a nastygram back from Greg
> about CC'ing the stable kernel alias directly. It's probably worth
> re-reading the Documentation/process/stable-kernel-rules.rst docs if
> you haven't done so in a while, it's a quick read and I do it myself
> every few months.
See above... I'll let you add the stable CC... maybe I should put this
in a patch comment *after* the --- separator after the patch description.
> * I generally ask that people *not* directly add the 'Cc: stable@...`
> tag to patches they send to the list, I prefer to add/remove those as
> needed. It's not a hard rule, just something I prefer (and don't
> respin patches *only* to remove the tag, but keep this in mind for
> future submissions/respins). If there is ever any concern about the
> stable tag I bring that up for discussion on-list, although that has
> only ever happened once (twice?) that I can recall; it's usually
> pretty obvious.
This audit_return_fixup() was pretty obvious, but there is other stuff
in there that isn't so urgent.
> * Despite what I said about the stable tagging, please continue to add
> the 'Fixes: ...' tags for serious bugs, those are good and welcome.
>
> * The audit_return_fixup() is definitely -rc/stable material, which
> means it should be split into its own patch.
>
> * The proctitle free change *might* be stable worthy, but I'd like to
> hear some more justification of this from you either in a reply on
> this thread or in a commit description. Regardless, just like the
> return fix, this should be in a separate patch.
>
> * The enum comparison should be its own patch, with an appropriate
> 'Fixes:' tag in case the -stable folks want to merge it, but as we
> haven't seen any problems with it (and they aren't likely) I wouldn't
> tag this for -stable.
>
> * I would suggest the audit_context::pid removal and the comment fix
> be separate patches as well. I would also suggest omitting a 'Fixes:'
> tag here as these are far from critical, and things with a fixes tag
> tend to get pulled into -stable kernels which I believe would be a
> mistake here.
I'll separate these into four patches...
> > diff --git a/kernel/audit.h b/kernel/audit.h
> > index 58b66543b4d5..d6eb7b59c791 100644
> > --- a/kernel/audit.h
> > +++ b/kernel/audit.h
> > @@ -133,7 +133,7 @@ struct audit_context {
> > struct sockaddr_storage *sockaddr;
> > size_t sockaddr_len;
> > /* Save things to print about task_struct */
> > - pid_t pid, ppid;
> > + pid_t ppid;
> > kuid_t uid, euid, suid, fsuid;
> > kgid_t gid, egid, sgid, fsgid;
> > unsigned long personality;
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index 9226746dcf0a..9f8c05228d6d 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -965,7 +965,7 @@ static void audit_reset_context(struct audit_context
> > *ctx)
> > if (!ctx)
> > return;
> >
> > - /* if ctx is non-null, reset the "ctx->state" regardless */
> > + /* if ctx is non-null, reset the "ctx->context" regardless */
> > ctx->context = AUDIT_CTX_UNUSED;
> > if (ctx->dummy)
> >
[PATCH ghak138] audit: move audit_return_fixup before the filters
The success and return_code are needed by the filters. Move
audit_return_fixup() before the filters.
The pid member of struct audit_context is never used. Remove it.
The audit_reset_context() comment about unconditionally resetting
"ctx->state" should read "ctx->context".
The proctitle is intentionally stored between syscalls. Only free it in
audit_free_context().
Be explicit in checking the struct audit_context "context" member enum
value rather than assuming the order of context enum values.
Cc: sta...@vger.kernel.org
Fixes: 12c5e81d3fd0 ("audit: prepare audit_context for use in calling contexts
beyond syscalls")
Signed-off-by: Richard Guy Briggs
---
kernel/audit.h | 2 +-
kernel/auditsc.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/kernel/audit.h b/kernel/audit.h
index 58b66543b4d5..d6eb7b59c791 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -133,7 +133,7 @@ struct audit_context {
struct sockaddr_storage *sockaddr;
size_t sockaddr_len;
/* Save things to print about task_struct */
- pid_t pid, ppid;
+ pid_t ppid;
kuid_t uid, euid, suid, fsuid;
kgid_t gid, egid, sgid, fsgid;
unsigned long personality;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 9226746dcf0a..9f8c05228d6d 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -965,7 +965,7 @@ static void audit_reset_context(struct audit_context *ctx)
if (!ctx)
return;
- /* if ctx is non-null, reset the "ctx->state" regardless */
+ /* if ctx is non-null, reset the "ctx->context" regardless */
ctx->context = AUDIT_CTX_UNUSED;
if (ctx->dummy)
return;
@@ -1002,7 +1002,7 @@ static void audit_reset_context(struct audit_context *ctx)
kfree(ctx->sockaddr);
ctx->sockaddr = NULL;
ctx->sockaddr_len = 0;
- ctx->pid = ctx->ppid = 0;
+ ctx->ppid = 0;
ctx->uid = ctx->euid = ctx->suid = ctx->fsuid = KUIDT_INIT(0);
ctx->gid = ctx->egid = ctx->sgid = ctx->fsgid = KGIDT_INIT(0);
ctx->personality = 0;
@@ -1016,7 +1016,6 @@ static void audit_reset_context(struct audit_context *ctx)
WARN_ON(!list_empty(>killed_trees));
audit_free_module(ctx);
ctx->fds[0] = -1;
- audit_proctitle_free(ctx);
ctx->type = 0; /* reset last for audit_free_*() */
}
@@ -1077,6 +1076,7 @@ static inline void audit_free_context(struct
audit_context *context)
{
/* resetting is extra work, but it is likely just noise */
audit_reset_context(context);
+ audit_proctitle_free(context);
free_tree_refs(context);
kfree(context->filterkey);
kfree(context);
@@ -1940,6 +1940,7 @@ void __audit_uring_exit(int success, long code)
goto out;
}
+ audit_return_fixup(ctx, success, code);
if (ctx->context == AUDIT_CTX_SYSCALL) {
/*
* NOTE: See the note in __audit_uring_entry() about the case
@@ -1981,7 +1982,6 @@ void __audit_uring_exit(int success, long code)
audit_filter_inodes(current, ctx);
if (ctx->current_state != AUDIT_STATE_RECORD)
goto out;
- audit_return_fixup(ctx, success, code);
audit_log_exit();
out:
@@ -2065,13 +2065,13 @@ void __audit_syscall_exit(int success, long return_code)
if (!list_empty(>killed_trees))
audit_kill_trees(context);
+ audit_return_fixup(context, success, return_code);
/* run through both filters to ensure we set the filterkey properly */
audit_filter_syscall(current, context);
audit_filter_inodes(current, context);
- if (context->current_state < AUDIT_STATE_RECORD)
+ if (context->current_state != AUDIT_STATE_RECORD)
goto out;
- audit_return_fixup(context, success, return_code);
audit_log_exit();
out:
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
On 2022-08-19 10:17, Nick Desaulniers wrote:
> On Fri, Aug 19, 2022 at 9:25 AM Richard Guy Briggs wrote:
> >
> > On 2022-08-10 22:28, kernel test robot wrote:
> > > Hi Richard,
> > >
> > > Thank you for the patch! Perhaps something to improve:
> > >
> > > [auto build test WARNING on jack-fs/fsnotify]
> > > [also build test WARNING on pcmoore-audit/next linus/master v5.19
> > > next-20220810]
> > > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > > And when submitting patch, we suggest to use '--base' as documented in
> > > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> > >
> > > url:
> > > https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > > base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git
> > > fsnotify
> > > config: i386-randconfig-a013
> > > (https://download.01.org/0day-ci/archive/20220810/202208102231.qsudyadb-...@intel.com/config)
> > > compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project
> > > 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
> > > reproduce (this is a W=1 build):
> > > wget
> > > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
> > > -O ~/bin/make.cross
> > > chmod +x ~/bin/make.cross
> > > #
> > > https://github.com/intel-lab-lkp/linux/commit/a943676abc023c094f05b45f4d61936c567507a2
> > > git remote add linux-review https://github.com/intel-lab-lkp/linux
> > > git fetch --no-tags linux-review
> > > Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > > git checkout a943676abc023c094f05b45f4d61936c567507a2
> > > # save the config file
> > > mkdir build_dir && cp config build_dir/.config
> > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
> > > O=build_dir ARCH=i386 SHELL=/bin/bash fs/notify/fanotify/
> > >
> > > If you fix the issue, kindly add following tag where applicable
> > > Reported-by: kernel test robot
> > >
> > > All warnings (new ones prefixed by >>):
> > >
> > > >> fs/notify/fanotify/fanotify_user.c:325:35: warning: format specifies
> > > >> type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned
> > > >> int') [-Wformat]
> >
> > Interesting. When I "fix" it, my compiler complains:
> >
> > fs/notify/fanotify/fanotify_user.c:324:11: warning: format ‘%u’
> > expects argument of type ‘unsigned int’, but argument 8 has type ‘size_t’
> > {aka ‘long unsigned int’} [-Wformat=]
>
> The correct format specifier for size_t is %zu. This avoids issues
> between ILP32 vs LP64 targets.
Perfect, thanks!
> > > group, fd, response, info_buf, count);
> > >^
> > >include/linux/printk.h:594:38: note: expanded from macro 'pr_debug'
> > >no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> > >~~~ ^~~
> > >include/linux/printk.h:131:17: note: expanded from macro 'no_printk'
> > >printk(fmt, ##__VA_ARGS__); \
> > > ~~~^~~
> > >include/linux/printk.h:464:60: note: expanded from macro 'printk'
> > >#define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
> > >~~~^~~
> > >include/linux/printk.h:436:19: note: expanded from macro
> > > 'printk_index_wrap'
> > >_p_func(_fmt, ##__VA_ARGS__);
> > > \
> > >^~~
> > >1 warning generated.
> > >
> > >
> > > vim +325 fs/notify/fanotify/fanotify_user.c
> > >
> > >312
> > >313static int process_access_response(struct fsnotify_group
> > > *group,
> > >314 struct fanotify_response
> > > *response_struct,
> > >315 const char __user *buf,
> > >316 size_t count)
> > >317{
&g
Re: [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string
On 2022-08-16 09:37, Steve Grubb wrote:
> 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.
Sure, these seem reasonable.
> Thanks,
> -Steve
>
> > + audit_log_end(ab);
> > +
> > + }
> > }
> > c -= friar->hdr.len;
> > ib += friar->hdr.len;
>
>
>
>
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
On 2022-08-10 22:28, kernel test robot wrote:
> Hi Richard,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on jack-fs/fsnotify]
> [also build test WARNING on pcmoore-audit/next linus/master v5.19
> next-20220810]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git
> fsnotify
> config: i386-randconfig-a013
> (https://download.01.org/0day-ci/archive/20220810/202208102231.qsudyadb-...@intel.com/config)
> compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project
> 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> #
> https://github.com/intel-lab-lkp/linux/commit/a943676abc023c094f05b45f4d61936c567507a2
> git remote add linux-review https://github.com/intel-lab-lkp/linux
> git fetch --no-tags linux-review
> Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> git checkout a943676abc023c094f05b45f4d61936c567507a2
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
> O=build_dir ARCH=i386 SHELL=/bin/bash fs/notify/fanotify/
>
> If you fix the issue, kindly add following tag where applicable
> Reported-by: kernel test robot
>
> All warnings (new ones prefixed by >>):
>
> >> fs/notify/fanotify/fanotify_user.c:325:35: warning: format specifies type
> >> 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int')
> >> [-Wformat]
Interesting. When I "fix" it, my compiler complains:
fs/notify/fanotify/fanotify_user.c:324:11: warning: format ‘%u’ expects
argument of type ‘unsigned int’, but argument 8 has type ‘size_t’ {aka ‘long
unsigned int’} [-Wformat=]
> group, fd, response, info_buf, count);
>^
>include/linux/printk.h:594:38: note: expanded from macro 'pr_debug'
>no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
>~~~ ^~~
>include/linux/printk.h:131:17: note: expanded from macro 'no_printk'
>printk(fmt, ##__VA_ARGS__); \
> ~~~^~~
>include/linux/printk.h:464:60: note: expanded from macro 'printk'
>#define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
>~~~^~~
>include/linux/printk.h:436:19: note: expanded from macro
> 'printk_index_wrap'
>_p_func(_fmt, ##__VA_ARGS__); \
>^~~
>1 warning generated.
>
>
> vim +325 fs/notify/fanotify/fanotify_user.c
>
>312
>313static int process_access_response(struct fsnotify_group *group,
>314 struct fanotify_response
> *response_struct,
>315 const char __user *buf,
>316 size_t count)
>317{
>318struct fanotify_perm_event *event;
>319int fd = response_struct->fd;
>320u32 response = response_struct->response;
>321struct fanotify_response_info_header info_hdr;
>322char *info_buf = NULL;
>323
>324pr_debug("%s: group=%p fd=%d response=%u buf=%p
> size=%lu\n", __func__,
> > 325 group, fd, response, info_buf, count);
>326/*
>327 * make sure the response is valid, if invalid we do
> nothing and either
>328 * userspace can send a valid response or we will clean
> it up after the
>329 * timeout
>330 */
>331if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
>332return -EINVAL;
>333switch (response & FANOTIFY_RESPONSE_ACCESS
Re: [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string
On 2022-08-10 15:15, Steve Grubb wrote:
> Hell Richard,
That's quite an introduction! ;-)
> 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.
Well, if it is to be consistently hex encoded, that corresponds to "?"
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.
> -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;
>
>
>
>
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response
This patch passes the full value 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. The following is an example of the new record
format:
type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=17
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 | 31 ---
3 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 0f36062521f4..36c3ed1af085 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -276,7 +276,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,
+ event->info_len, event->info_buf);
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 3ea198a2cd59..c69efdba12ca 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)
@@ -417,7 +418,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, size_t len, char *buf);
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,
@@ -524,10 +525,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, size_t len, char *buf)
{
if (!audit_dummy_context())
- __audit_fanotify(response);
+ __audit_fanotify(response, len, buf);
}
static inline void audit_tk_injoffset(struct timespec64 offset)
@@ -684,7 +685,7 @@ static inline void audit_log_kern_module(char *name)
{
}
-static inline void audit_fanotify(u32 response)
+static inline void audit_fanotify(u32 response, size_t len, char *buf)
{ }
static inline void audit_tk_injoffset(struct timespec64 offset)
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;
+ 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);
+ return;
+ }
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=%u fan_info=%u",
+ response, friar->hdr.type, friar->audit_rule);
+ }
+ c -= friar->hdr.len;
+ ib += friar->hdr.len;
+ }
}
void __audit_tk_injoffset(struct timespec64 offset)
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string
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));
+ audit_log_end(ab);
+
+ }
}
c -= friar->hdr.len;
ib += friar->hdr.len;
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info
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 for audit 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.
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_info=3F
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/r/cover.1652724390.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/r/cover.1659981772.git@redhat.com
Richard Guy Briggs (4):
fanotify: Ensure consistent variable type for response
fanotify: define struct members to hold response decision context
fanotify,audit: Allow audit to use the full permission event response
fanotify,audit: deliver fan_info as a hex-encoded string
fs/notify/fanotify/fanotify.c | 13 +++-
fs/notify/fanotify/fanotify.h | 4 +-
fs/notify/fanotify/fanotify_user.c | 106 ++---
include/linux/audit.h | 9 +--
include/linux/fanotify.h | 5 ++
include/uapi/linux/fanotify.h | 27 +++-
kernel/auditsc.c | 45 +++-
7 files changed, 174 insertions(+), 35 deletions(-)
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v4 1/4] fanotify: Ensure consistent variable type for response
The user space API for the response variable is __u32. This patch makes
sure that the whole path through the kernel uses u32 so that there is
no sign extension or truncation of the user space response.
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/12617626.uLZWGnKmhe@x2
Signed-off-by: Richard Guy Briggs
---
fs/notify/fanotify/fanotify.h | 2 +-
fs/notify/fanotify/fanotify_user.c | 6 +++---
include/linux/audit.h | 6 +++---
kernel/auditsc.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index 80e0ec95b113..abfa3712c185 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -425,7 +425,7 @@ FANOTIFY_PE(struct fanotify_event *event)
struct fanotify_perm_event {
struct fanotify_event fae;
struct path path;
- unsigned short response;/* userspace answer to the event */
+ u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
};
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index c2255b440df9..ff67ca0d25cc 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -289,7 +289,7 @@ static int create_fd(struct fsnotify_group *group, struct
path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- unsigned int response)
+ u32 response)
__releases(>notification_lock)
{
bool destroy = false;
@@ -310,9 +310,9 @@ static int process_access_response(struct fsnotify_group
*group,
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
- int response = response_struct->response;
+ u32 response = response_struct->response;
- pr_debug("%s: group=%p fd=%d response=%d\n", __func__, group,
+ pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
fd, response);
/*
* make sure the response is valid, if invalid we do nothing and either
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 00f7a80f1a3e..3ea198a2cd59 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -417,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(unsigned int response);
+extern void __audit_fanotify(u32 response);
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,
@@ -524,7 +524,7 @@ static inline void audit_log_kern_module(char *name)
__audit_log_kern_module(name);
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{
if (!audit_dummy_context())
__audit_fanotify(response);
@@ -684,7 +684,7 @@ static inline void audit_log_kern_module(char *name)
{
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{ }
static inline void audit_tk_injoffset(struct timespec64 offset)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index f3a2abd6d1a1..433418d73584 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2899,7 +2899,7 @@ void __audit_log_kern_module(char *name)
context->type = AUDIT_KERN_MODULE;
}
-void __audit_fanotify(unsigned int response)
+void __audit_fanotify(u32 response)
{
audit_log(audit_context(), GFP_KERNEL,
AUDIT_FANOTIFY, "resp=%u", response);
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v4 2/4] fanotify: define struct members to hold response decision context
This patch adds a flag, FAN_INFO and an extensible buffer to provide
additional information about response decisions. The buffer contains
one or more headers defining the information type and the length of the
following information. The patch defines one additional information
type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will
allow for the creation of other information types in the future if other
users of the API identify different needs.
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
Suggested-by: Jan Kara
Link: https://lore.kernel.org/r/20201001101219.ge17...@quack2.suse.cz
Signed-off-by: Richard Guy Briggs
---
fs/notify/fanotify/fanotify.c | 10 ++-
fs/notify/fanotify/fanotify.h | 2 +
fs/notify/fanotify/fanotify_user.c | 104 +++--
include/linux/fanotify.h | 5 ++
include/uapi/linux/fanotify.h | 27 +++-
5 files changed, 123 insertions(+), 25 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 4f897e109547..0f36062521f4 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -262,13 +262,16 @@ static int fanotify_get_response(struct fsnotify_group
*group,
}
/* userspace responded, convert to something usable */
- switch (event->response & ~FAN_AUDIT) {
+ switch (event->response & FANOTIFY_RESPONSE_ACCESS) {
case FAN_ALLOW:
ret = 0;
break;
case FAN_DENY:
- default:
ret = -EPERM;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
}
/* Check if the response should be audited */
@@ -560,6 +563,8 @@ static struct fanotify_event
*fanotify_alloc_perm_event(const struct path *path,
pevent->fae.type = FANOTIFY_EVENT_TYPE_PATH_PERM;
pevent->response = 0;
+ pevent->info_len = 0;
+ pevent->info_buf = NULL;
pevent->state = FAN_EVENT_INIT;
pevent->path = *path;
path_get(path);
@@ -996,6 +1001,7 @@ static void fanotify_free_path_event(struct fanotify_event
*event)
static void fanotify_free_perm_event(struct fanotify_event *event)
{
path_put(fanotify_event_path(event));
+ kfree(FANOTIFY_PERM(event)->info_buf);
kmem_cache_free(fanotify_perm_event_cachep, FANOTIFY_PERM(event));
}
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index abfa3712c185..14c30e173632 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -428,6 +428,8 @@ struct fanotify_perm_event {
u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
+ size_t info_len;
+ char *info_buf;
};
static inline struct fanotify_perm_event *
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index ff67ca0d25cc..a4ae953f0e62 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -289,13 +289,18 @@ static int create_fd(struct fsnotify_group *group, struct
path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- u32 response)
+ struct fanotify_response *response,
+ size_t info_len, char *info_buf)
__releases(>notification_lock)
{
bool destroy = false;
assert_spin_locked(>notification_lock);
- event->response = response;
+ event->response = response->response & ~FAN_INFO;
+ if (response->response & FAN_INFO) {
+ event->info_len = info_len;
+ event->info_buf = info_buf;
+ }
if (event->state == FAN_EVENT_CANCELED)
destroy = true;
else
@@ -306,33 +311,71 @@ static void finish_permission_event(struct fsnotify_group
*group,
}
static int process_access_response(struct fsnotify_group *group,
- struct fanotify_response *response_struct)
+ struct fanotify_response *response_struct,
+ const char __user *buf,
+ size_t count)
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
u32 response = response_struct->response;
+ struct fanotify_response_info_header info_hdr;
+ char *info_buf = NULL;
- pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
-fd, response);
+ pr_debug("%s: group=%p fd=%d resp
Re: [EXTERNAL] Re: Help setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr
On 2022-05-19 20:19, Alex Triantafillidis (DESIGN LABORATORY INC) wrote: > HI Paul, > Thank you for the quick response. > I am rusty on linux and I might be confused. > The question is, can I directly call any of those > (setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr) directly > from the command line, or they need to be a part of a script. Not generally. Scripts can be built to call these syscalls depending on the scripting environment. > Is it possible that those are not installed in cbl-mariner? I would say so > but I cannot find a package available in mariner github. The only thing I > found similar is “attr”, but using it as a rule instead of lets say setxattr > it wont even register as a rule. I doubt it. > Any attempt to run the > setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr) returns > “command not found” This is a list of linux kernel (unix? posix?) syscalls. There are a few syscalls that have commands named for them, but generally syscalls are used by applications to manipulate system resources (memory, disk, networks, cpus, etc...) > How can I repro those rules without being able to use the commands to modify > a file/directory? Use an existing test suite, write a script or application to exercise these rules. > Regards. > AlexT > > From: Paul Moore > Date: Thursday, May 19, 2022 at 12:46 PM > To: Alex Triantafillidis (DESIGN LABORATORY INC) > Cc: linux-audit@redhat.com > Subject: [EXTERNAL] Re: Help > setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr > [You don't often get email from p...@paul-moore.com. Learn why this is > important at > https://aka.ms/LearnAboutSenderIdentification.]<https://aka.ms/LearnAboutSenderIdentification.%5d> > > On Thu, May 19, 2022 at 12:45 PM Alex Triantafillidis (DESIGN > LABORATORY INC) wrote: > > > > Hello Audit, > > > > I am trying to implement a set of rules related to “xattrs” on a MS > > CBL-Mariner 1.0. > > > > I am following this guide. > > > > Record Events that Modify the System's Discretionary Access Controls > > Group contains 13 rules > > > > [ref] At a minimum, the audit system should collect file permission > > changes for all users and root. Note that the "-F arch=b32" lines should be > > present even on a 64 bit system. These commands identify system calls for > > auditing. Even if the system is 64 bit it can still execute 32 bit system > > calls. Additionally, these rules can be configured in a number of ways > > while still achieving the desired effect. An example of this is that the > > "-S" calls could be split up and placed on separate lines, however, this is > > less efficient. Add the following to /etc/audit/audit.rules: > > > > -a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F > > auid!=unset -F key=perm_mod > > > > -a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F > > auid>=1000 -F auid!=unset -F key=perm_mod > > > > -a always,exit -F arch=b32 -S > > setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F > > auid>=1000 -F auid!=unset -F key=perm_mod > > > > If your system is 64 bit then these lines should be duplicated and the > > arch=b32 replaced with arch=b64 as follows: > > > > -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F > > auid!=unset -F key=perm_mod > > > > -a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F > > auid>=1000 -F auid!=unset -F key=perm_mod > > > > -a always,exit -F arch=b64 -S > > setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F > > auid>=1000 -F auid!=unset -F key=perm_mod > > > > > > > > Thing is I get error to any of > > setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr. > > > > bash: setxattr: command not found > > Hi Alex, > > Are you trying to execute the /etc/audit/audit.rules file directly > (like it was a bash script)? I'm asking because the error you are > getting makes it look like bash is trying to execute a program named > "setxattr" which isn't going to work; the lines in audit.rules are > intended to be passed as command line arguments to auditctl. Look at > the augenrules script (repo link below) and the auditctl '-R' option. > > * > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flinux-audit%2Faudit-userspace%2Fblob%2Fmaster%2Finit.d%2Faugenrulesdata=05%7C01%7Cv-alextri%40microsoft.com%7C23e034c36d7044eee08b08da39d029cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637
Re: [PATCH v3 2/3] fanotify: define struct members to hold response decision context
On 2022-05-17 08:37, Amir Goldstein wrote:
> On Mon, May 16, 2022 at 11:22 PM Richard Guy Briggs wrote:
> >
> > This patch adds 2 structure members to the response returned from user
> > space on a permission event. The first field is 32 bits for the context
> > type. The context type will describe what the meaning is of the second
> > field. The default is none. The patch defines one additional context
> > type which means that the second field is a union containing a 32-bit
> > rule number. This will allow for the creation of other context types in
> > the future if other users of the API identify different needs. The
> > second field size is defined by the context type and can be used to pass
> > along the data described by the context.
> >
> > To support this, there is a macro for user space to check that the data
> > being sent is valid. Of course, without this check, anything that
> > overflows the bit field will trigger an EINVAL based on the use of
> > FAN_INVALID_RESPONSE_MASK in process_access_response().
> >
> > Suggested-by: Steve Grubb
> > Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> > Suggested-by: Jan Kara
> > Link: https://lore.kernel.org/r/20201001101219.ge17...@quack2.suse.cz
> > Signed-off-by: Richard Guy Briggs
> > ---
> > fs/notify/fanotify/fanotify.c | 2 +-
> > fs/notify/fanotify/fanotify.h | 2 +
> > fs/notify/fanotify/fanotify_user.c | 74 +++---
> > include/linux/fanotify.h | 3 ++
> > include/uapi/linux/fanotify.h | 22 -
> > 5 files changed, 75 insertions(+), 28 deletions(-)
> >
> > diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> > index 985e995d2a39..ea0e60488f12 100644
> > --- a/fs/notify/fanotify/fanotify.c
> > +++ b/fs/notify/fanotify/fanotify.c
> > @@ -262,7 +262,7 @@ static int fanotify_get_response(struct fsnotify_group
> > *group,
> > }
> >
> > /* userspace responded, convert to something usable */
> > - switch (event->response & ~FAN_AUDIT) {
> > + switch (event->response & ~(FAN_AUDIT | FAN_EXTRA)) {
> > case FAN_ALLOW:
> > ret = 0;
> > break;
> > diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
> > index d8e06bee..eb7ec1f2a26e 100644
> > --- a/fs/notify/fanotify/fanotify.h
> > +++ b/fs/notify/fanotify/fanotify.h
> > @@ -426,8 +426,10 @@ struct fanotify_perm_event {
> > struct fanotify_event fae;
> > struct path path;
> > u32 response; /* userspace answer to the event */
> > + u32 extra_info_type;
> > unsigned short state; /* state of the event */
> > int fd; /* fd we passed to userspace for this event */
> > + union fanotify_response_extra extra_info;
> > };
> >
> > static inline struct fanotify_perm_event *
> > diff --git a/fs/notify/fanotify/fanotify_user.c
> > b/fs/notify/fanotify/fanotify_user.c
> > index 721e777ea90b..1c4067e29f2e 100644
> > --- a/fs/notify/fanotify/fanotify_user.c
> > +++ b/fs/notify/fanotify/fanotify_user.c
> > @@ -289,13 +289,22 @@ static int create_fd(struct fsnotify_group *group,
> > struct path *path,
> > */
> > static void finish_permission_event(struct fsnotify_group *group,
> > struct fanotify_perm_event *event,
> > - u32 response)
> > + struct fanotify_response *response)
> > __releases(>notification_lock)
> > {
> > bool destroy = false;
> >
> > assert_spin_locked(>notification_lock);
> > - event->response = response;
> > + event->response = response->response & ~FAN_EXTRA;
> > + if (response->response & FAN_EXTRA) {
> > + event->extra_info_type = response->extra_info_type;
> > + switch (event->extra_info_type) {
> > + case FAN_RESPONSE_INFO_AUDIT_RULE:
> > + event->extra_info.audit_rule =
> > response->extra_info.audit_rule;
> > + }
> > + } else {
> > + event->extra_info_type = FAN_RESPONSE_INFO_NONE;
> > + }
> > if (event->state == FAN_EVENT_CANCELED)
> > destroy = true;
> > else
> > @@ -306,33 +315,40 @@ static void finish_p
Re: [PATCH v3 3/3] fanotify: Allow audit to use the full permission event response
On 2022-05-16 21:42, Paul Moore wrote:
> On Mon, May 16, 2022 at 4:22 PM Richard Guy Briggs wrote:
> >
> > This patch passes the full value 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. 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
> >
> > Suggested-by: Steve Grubb
> > Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2
> > Signed-off-by: Richard Guy Briggs
> > ---
> > fs/notify/fanotify/fanotify.c | 4 +++-
> > include/linux/audit.h | 9 +
> > kernel/auditsc.c | 18 +++---
> > 3 files changed, 23 insertions(+), 8 deletions(-)
>
> ...
>
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index 6973be0bf6c9..cb93c6ed07cd 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -2893,10 +2894,21 @@ void __audit_log_kern_module(char *name)
> > context->type = AUDIT_KERN_MODULE;
> > }
> >
> > -void __audit_fanotify(u32 response)
> > +void __audit_fanotify(u32 response, u32 type, union
> > fanotify_response_extra *info)
> > {
> > - audit_log(audit_context(), GFP_KERNEL,
> > - AUDIT_FANOTIFY, "resp=%u", response);
> > + switch (type) {
> > + case FAN_RESPONSE_INFO_AUDIT_RULE:
> > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > + "resp=%u fan_type=%u fan_ctx=%u",
> > + response, type, info->audit_rule);
> > + break;
> > + case FAN_RESPONSE_INFO_NONE:
> > + default:
> > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > + "resp=%u fan_type=%u fan_ctx=?",
> > + response, type);
> > + break;
> > + }
> > }
>
> Two things:
>
> * Instead of "fan_ctx=", would it make sense to call it "fan_extra="
> to better match the UAPI struct? I don't feel strongly either way,
> but it did occur to me just now while looking at the code so I thought
> I would mention it.
Yes, this is a good point. This is the reason I changed from
FAN_RESPONSE_INFO_AUDIT_NONE to FAN_RESPONSE_INFO_NONE, anticipating
that the extra information could have nothing to do with audit.
> * I'm also wondering if there is a way to be a bit proactive about
> future proofing this field. Since we already hex encode some fields
> with "bad" characters, would it make sense to hex encode this field
> too? Not for the "bad" character reason, but more as a way of
> marshalling the fanotify_response_extra union into an audit record. I
> can't see far enough into the future to know if this would be a good
> idea or not, but like the other point above, it popped into my head
> while looking at the code so I thought I would put it in the email :)
I resisted that idea because it adds overhead and makes it more complex
than currently necessary. I'm open to it, but would like to hear
Steve's input on this.
Thanks for the quick response.
> paul-moore.com
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v2 2/3] fanotify: define struct members to hold response decision context
On 2022-05-09 10:54, Jan Kara wrote:
> On Fri 06-05-22 14:46:49, Richard Guy Briggs wrote:
> > On 2022-05-05 16:44, Jan Kara wrote:
> > > On Tue 03-05-22 21:33:35, Richard Guy Briggs wrote:
> > > > On 2022-05-02 20:16, Paul Moore wrote:
> > > > > On Thu, Apr 28, 2022 at 8:45 PM Richard Guy Briggs
> > > > > wrote:
> > > > > > This patch adds 2 structure members to the response 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 default is none. The patch defines one additional context
> > > > > > type which means that the second field is a 32-bit rule number. This
> > > > > > will allow for the creation of other context types in the future if
> > > > > > other users of the API identify different needs. The second field
> > > > > > size
> > > > > > is defined by the context type and can be used to pass along the
> > > > > > data
> > > > > > described by the context.
> > > > > >
> > > > > > To support this, there is a macro for user space to check that the
> > > > > > data
> > > > > > being sent is valid. Of course, without this check, anything that
> > > > > > overflows the bit field will trigger an EINVAL based on the use of
> > > > > > FAN_INVALID_RESPONSE_MASK in process_access_response().
> > > > > >
> > >
> > > ...
> > >
> > > > > > static ssize_t fanotify_write(struct file *file, const char __user
> > > > > > *buf, size_t count, loff_t *pos)
> > > > > > {
> > > > > > - struct fanotify_response response = { .fd = -1, .response =
> > > > > > -1 };
> > > > > > + struct fanotify_response response;
> > > > > > struct fsnotify_group *group;
> > > > > > int ret;
> > > > > > + size_t size = min(count, sizeof(struct fanotify_response));
> > > > > >
> > > > > > if (!IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS))
> > > > > > return -EINVAL;
> > > > > >
> > > > > > group = file->private_data;
> > > > > >
> > > > > > - if (count < sizeof(response))
> > > > > > + if (count < offsetof(struct fanotify_response,
> > > > > > extra_info_buf))
> > > > > > return -EINVAL;
> > > > >
> > > > > Is this why you decided to shrink the fanotify_response:response field
> > > > > from 32-bits to 16-bits? I hope not. I would suggest both keeping
> > > > > the existing response field as 32-bits and explicitly checking for
> > > > > writes that are either the existing/compat length as well as the
> > > > > newer, longer length.
> > > >
> > > > No. I shrank it at Jan's suggestion. I think I agree with you that
> > > > the response field should be kept at u32 as it is defined in userspace
> > > > and purge the doubt about what would happen with a new userspace with
> > > > an old kernel.
> > >
> > > Hum, for the life of me I cannot find my response you mention here. Can
> > > you
> > > send a link so that I can refresh my memory? It has been a long time...
> >
> > https://listman.redhat.com/archives/linux-audit/2020-October/017066.html
> > https://listman.redhat.com/archives/linux-audit/2020-October/017067.html
>
> Thanks!
>
> > > > > > +
> > > > > > +#define FANOTIFY_RESPONSE_EXTRA_LEN_MAX\
> > > > > > + (sizeof(union { \
> > > > > > + struct fanotify_response_audit_rule r; \
> > > > > > + /* add other extra info structures here */ \
> > > > > > + }))
> > > > > > +
> > > > > > struct fanotify_response {
> > > > > > __s32 fd;
> > > > > > - __u32 response;
> > > > > > + __u16 response;
> > > > > > + __u16 extra_info_type;
> >
[PATCH v3 2/3] fanotify: define struct members to hold response decision context
This patch adds 2 structure members to the response returned from user
space on a permission event. The first field is 32 bits for the context
type. The context type will describe what the meaning is of the second
field. The default is none. The patch defines one additional context
type which means that the second field is a union containing a 32-bit
rule number. This will allow for the creation of other context types in
the future if other users of the API identify different needs. The
second field size is defined by the context type and can be used to pass
along the data described by the context.
To support this, there is a macro for user space to check that the data
being sent is valid. Of course, without this check, anything that
overflows the bit field will trigger an EINVAL based on the use of
FAN_INVALID_RESPONSE_MASK in process_access_response().
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
Suggested-by: Jan Kara
Link: https://lore.kernel.org/r/20201001101219.ge17...@quack2.suse.cz
Signed-off-by: Richard Guy Briggs
---
fs/notify/fanotify/fanotify.c | 2 +-
fs/notify/fanotify/fanotify.h | 2 +
fs/notify/fanotify/fanotify_user.c | 74 +++---
include/linux/fanotify.h | 3 ++
include/uapi/linux/fanotify.h | 22 -
5 files changed, 75 insertions(+), 28 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 985e995d2a39..ea0e60488f12 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -262,7 +262,7 @@ static int fanotify_get_response(struct fsnotify_group
*group,
}
/* userspace responded, convert to something usable */
- switch (event->response & ~FAN_AUDIT) {
+ switch (event->response & ~(FAN_AUDIT | FAN_EXTRA)) {
case FAN_ALLOW:
ret = 0;
break;
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index d8e06bee..eb7ec1f2a26e 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -426,8 +426,10 @@ struct fanotify_perm_event {
struct fanotify_event fae;
struct path path;
u32 response; /* userspace answer to the event */
+ u32 extra_info_type;
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
+ union fanotify_response_extra extra_info;
};
static inline struct fanotify_perm_event *
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index 721e777ea90b..1c4067e29f2e 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -289,13 +289,22 @@ static int create_fd(struct fsnotify_group *group, struct
path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- u32 response)
+ struct fanotify_response *response)
__releases(>notification_lock)
{
bool destroy = false;
assert_spin_locked(>notification_lock);
- event->response = response;
+ event->response = response->response & ~FAN_EXTRA;
+ if (response->response & FAN_EXTRA) {
+ event->extra_info_type = response->extra_info_type;
+ switch (event->extra_info_type) {
+ case FAN_RESPONSE_INFO_AUDIT_RULE:
+ event->extra_info.audit_rule =
response->extra_info.audit_rule;
+ }
+ } else {
+ event->extra_info_type = FAN_RESPONSE_INFO_NONE;
+ }
if (event->state == FAN_EVENT_CANCELED)
destroy = true;
else
@@ -306,33 +315,40 @@ static void finish_permission_event(struct fsnotify_group
*group,
}
static int process_access_response(struct fsnotify_group *group,
- struct fanotify_response *response_struct)
+ struct fanotify_response *response_struct,
+ size_t count)
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
u32 response = response_struct->response;
- pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
-fd, response);
+ pr_debug("%s: group=%p fd=%d response=%u type=%u size=%lu\n", __func__,
+group, fd, response, response_struct->extra_info_type, count);
+ if (fd < 0)
+ return -EINVAL;
/*
* make sure the response is valid, if invalid we do nothing and either
* userspace can send a valid response or we will clean it up after the
* timeout
[PATCH v3 3/3] fanotify: Allow audit to use the full permission event response
This patch passes the full value 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. 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
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2
Signed-off-by: Richard Guy Briggs
---
fs/notify/fanotify/fanotify.c | 4 +++-
include/linux/audit.h | 9 +
kernel/auditsc.c | 18 +++---
3 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index ea0e60488f12..85ce36e59e0c 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -273,7 +273,9 @@ 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,
+ event->extra_info_type,
+ >extra_info);
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 217784d602b3..737f1c109aa1 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)
@@ -419,7 +420,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, u32 type, union
fanotify_response_extra *info);
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,
@@ -526,10 +527,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, u32 type, union
fanotify_response_extra *info)
{
if (!audit_dummy_context())
- __audit_fanotify(response);
+ __audit_fanotify(response, type, info);
}
static inline void audit_tk_injoffset(struct timespec64 offset)
@@ -686,7 +687,7 @@ static inline void audit_log_kern_module(char *name)
{
}
-static inline void audit_fanotify(u32 response)
+static inline void audit_fanotify(u32 response, u32 type, union
fanotify_response_extra *info)
{ }
static inline void audit_tk_injoffset(struct timespec64 offset)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 6973be0bf6c9..cb93c6ed07cd 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -64,6 +64,7 @@
#include
#include
#include // struct open_how
+#include
#include "audit.h"
@@ -2893,10 +2894,21 @@ void __audit_log_kern_module(char *name)
context->type = AUDIT_KERN_MODULE;
}
-void __audit_fanotify(u32 response)
+void __audit_fanotify(u32 response, u32 type, union fanotify_response_extra
*info)
{
- audit_log(audit_context(), GFP_KERNEL,
- AUDIT_FANOTIFY, "resp=%u", response);
+ switch (type) {
+ case FAN_RESPONSE_INFO_AUDIT_RULE:
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=%u fan_ctx=%u",
+ response, type, info->audit_rule);
+ break;
+ case FAN_RESPONSE_INFO_NONE:
+ default:
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=%u fan_ctx=?",
+ response, type);
+ break;
+ }
}
void __audit_tk_injoffset(struct timespec64 offset)
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v3 1/3] fanotify: Ensure consistent variable type for response
The user space API for the response variable is __u32. This patch makes
sure that the whole path through the kernel uses u32 so that there is
no sign extension or truncation of the user space response.
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/12617626.uLZWGnKmhe@x2
Signed-off-by: Richard Guy Briggs
---
fs/notify/fanotify/fanotify.h | 2 +-
fs/notify/fanotify/fanotify_user.c | 6 +++---
include/linux/audit.h | 6 +++---
kernel/auditsc.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index a3d5b751cac5..d8e06bee 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -425,7 +425,7 @@ FANOTIFY_PE(struct fanotify_event *event)
struct fanotify_perm_event {
struct fanotify_event fae;
struct path path;
- unsigned short response;/* userspace answer to the event */
+ u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
};
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index 9b32b76a9c30..721e777ea90b 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -289,7 +289,7 @@ static int create_fd(struct fsnotify_group *group, struct
path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- unsigned int response)
+ u32 response)
__releases(>notification_lock)
{
bool destroy = false;
@@ -310,9 +310,9 @@ static int process_access_response(struct fsnotify_group
*group,
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
- int response = response_struct->response;
+ u32 response = response_struct->response;
- pr_debug("%s: group=%p fd=%d response=%d\n", __func__, group,
+ pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
fd, response);
/*
* make sure the response is valid, if invalid we do nothing and either
diff --git a/include/linux/audit.h b/include/linux/audit.h
index d06134ac6245..217784d602b3 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -419,7 +419,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(unsigned int response);
+extern void __audit_fanotify(u32 response);
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,
@@ -526,7 +526,7 @@ static inline void audit_log_kern_module(char *name)
__audit_log_kern_module(name);
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{
if (!audit_dummy_context())
__audit_fanotify(response);
@@ -686,7 +686,7 @@ static inline void audit_log_kern_module(char *name)
{
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{ }
static inline void audit_tk_injoffset(struct timespec64 offset)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index ea2ee1181921..6973be0bf6c9 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2893,7 +2893,7 @@ void __audit_log_kern_module(char *name)
context->type = AUDIT_KERN_MODULE;
}
-void __audit_fanotify(unsigned int response)
+void __audit_fanotify(u32 response)
{
audit_log(audit_context(), GFP_KERNEL,
AUDIT_FANOTIFY, "resp=%u", response);
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v3 0/3] fanotify: Allow user space to pass back additional audit info
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 32
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
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/r/cover.1652724390.git@redhat.com
Richard Guy Briggs (3):
fanotify: Ensure consistent variable type for response
fanotify: define struct members to hold response decision context
fanotify: Allow audit to use the full permission event response
fs/notify/fanotify/fanotify.c | 6 ++-
fs/notify/fanotify/fanotify.h | 4 +-
fs/notify/fanotify/fanotify_user.c | 76 +++---
include/linux/audit.h | 9 ++--
include/linux/fanotify.h | 3 ++
include/uapi/linux/fanotify.h | 22 -
kernel/auditsc.c | 18 +--
7 files changed, 100 insertions(+), 38 deletions(-)
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v2 2/3] fanotify: define struct members to hold response decision context
On 2022-05-05 16:44, Jan Kara wrote:
> On Tue 03-05-22 21:33:35, Richard Guy Briggs wrote:
> > On 2022-05-02 20:16, Paul Moore wrote:
> > > On Thu, Apr 28, 2022 at 8:45 PM Richard Guy Briggs
> > > wrote:
> > > > This patch adds 2 structure members to the response 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 default is none. The patch defines one additional context
> > > > type which means that the second field is a 32-bit rule number. This
> > > > will allow for the creation of other context types in the future if
> > > > other users of the API identify different needs. The second field size
> > > > is defined by the context type and can be used to pass along the data
> > > > described by the context.
> > > >
> > > > To support this, there is a macro for user space to check that the data
> > > > being sent is valid. Of course, without this check, anything that
> > > > overflows the bit field will trigger an EINVAL based on the use of
> > > > FAN_INVALID_RESPONSE_MASK in process_access_response().
> > > >
>
> ...
>
> > > > static ssize_t fanotify_write(struct file *file, const char __user
> > > > *buf, size_t count, loff_t *pos)
> > > > {
> > > > - struct fanotify_response response = { .fd = -1, .response = -1
> > > > };
> > > > + struct fanotify_response response;
> > > > struct fsnotify_group *group;
> > > > int ret;
> > > > + size_t size = min(count, sizeof(struct fanotify_response));
> > > >
> > > > if (!IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS))
> > > > return -EINVAL;
> > > >
> > > > group = file->private_data;
> > > >
> > > > - if (count < sizeof(response))
> > > > + if (count < offsetof(struct fanotify_response, extra_info_buf))
> > > > return -EINVAL;
> > >
> > > Is this why you decided to shrink the fanotify_response:response field
> > > from 32-bits to 16-bits? I hope not. I would suggest both keeping
> > > the existing response field as 32-bits and explicitly checking for
> > > writes that are either the existing/compat length as well as the
> > > newer, longer length.
> >
> > No. I shrank it at Jan's suggestion. I think I agree with you that
> > the response field should be kept at u32 as it is defined in userspace
> > and purge the doubt about what would happen with a new userspace with
> > an old kernel.
>
> Hum, for the life of me I cannot find my response you mention here. Can you
> send a link so that I can refresh my memory? It has been a long time...
https://listman.redhat.com/archives/linux-audit/2020-October/017066.html
https://listman.redhat.com/archives/linux-audit/2020-October/017067.html
> > > > +
> > > > +#define FANOTIFY_RESPONSE_EXTRA_LEN_MAX\
> > > > + (sizeof(union { \
> > > > + struct fanotify_response_audit_rule r; \
> > > > + /* add other extra info structures here */ \
> > > > + }))
> > > > +
> > > > struct fanotify_response {
> > > > __s32 fd;
> > > > - __u32 response;
> > > > + __u16 response;
> > > > + __u16 extra_info_type;
> > > > + char extra_info_buf[FANOTIFY_RESPONSE_EXTRA_LEN_MAX];
> > > > };
> > >
> > > Since both the kernel and userspace are going to need to agree on the
> > > content and formatting of the fanotify_response:extra_info_buf field,
> > > why is it hidden behind a char array? You might as well get rid of
> > > that abstraction and put the union directly in the fanotify_response
> > > struct. It is possible you could also get rid of the
> > > fanotify_response_audit_rule struct this way too and just access the
> > > rule scalar directly.
> >
> > This does make sense and my only concern would be a variable-length
> > type. There isn't any reason to hide it. If userspace chooses to use
> > the old interface and omit the type field then it defaults to NONE.
> >
> > If future types with variable data are defined, the first field could be
> > a u32 that unions with the rule number that won't change t
Re: [PATCH v2 2/3] fanotify: define struct members to hold response decision context
On 2022-05-02 20:16, Paul Moore wrote:
> On Thu, Apr 28, 2022 at 8:45 PM Richard Guy Briggs wrote:
> > This patch adds 2 structure members to the response 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 default is none. The patch defines one additional context
> > type which means that the second field is a 32-bit rule number. This
> > will allow for the creation of other context types in the future if
> > other users of the API identify different needs. The second field size
> > is defined by the context type and can be used to pass along the data
> > described by the context.
> >
> > To support this, there is a macro for user space to check that the data
> > being sent is valid. Of course, without this check, anything that
> > overflows the bit field will trigger an EINVAL based on the use of
> > FAN_INVALID_RESPONSE_MASK in process_access_response().
> >
> > Suggested-by: Steve Grubb
> > Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> > Suggested-by: Jan Kara
> > Link: https://lore.kernel.org/r/20201001101219.ge17...@quack2.suse.cz
> > Signed-off-by: Richard Guy Briggs
> > Link:
> > https://lore.kernel.org/r/17660b3f2817e5c0a19d1e9e5d40b53ff4561845.1651174324.git@redhat.com
> > ---
> > fs/notify/fanotify/fanotify.c | 1 -
> > fs/notify/fanotify/fanotify.h | 4 +-
> > fs/notify/fanotify/fanotify_user.c | 59 --
> > include/linux/fanotify.h | 3 ++
> > include/uapi/linux/fanotify.h | 27 +-
> > 5 files changed, 72 insertions(+), 22 deletions(-)
> >
> > diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> > index 985e995d2a39..00aff6e29bf8 100644
> > --- a/fs/notify/fanotify/fanotify.c
> > +++ b/fs/notify/fanotify/fanotify.c
> > @@ -266,7 +266,6 @@ static int fanotify_get_response(struct fsnotify_group
> > *group,
> > case FAN_ALLOW:
> > ret = 0;
> > break;
> > - case FAN_DENY:
>
> I personally would drop this from the patch if it was me, it doesn't
> change the behavior so it falls under the "noise" category, which
> could be a problem considering the lack of response on the original
> posting and this one. Small, focused patches have a better shot of
> review/merging.
It was a harmless part of the original patch, but I agree it should go.
> > default:
> > ret = -EPERM;
> > }
>
> ...
>
> > diff --git a/fs/notify/fanotify/fanotify_user.c
> > b/fs/notify/fanotify/fanotify_user.c
> > index 694516470660..f1ff4cf683fb 100644
> > --- a/fs/notify/fanotify/fanotify_user.c
> > +++ b/fs/notify/fanotify/fanotify_user.c
> > @@ -289,13 +289,19 @@ static int create_fd(struct fsnotify_group *group,
> > struct path *path,
> > */
> > static void finish_permission_event(struct fsnotify_group *group,
> > struct fanotify_perm_event *event,
> > - __u32 response)
> > + struct fanotify_response *response)
> > __releases(>notification_lock)
> > {
> > bool destroy = false;
> >
> > assert_spin_locked(>notification_lock);
> > - event->response = response;
> > + event->response = response->response;
> > + event->extra_info_type = response->extra_info_type;
> > + switch (event->extra_info_type) {
> > + case FAN_RESPONSE_INFO_AUDIT_RULE:
> > + memcpy(event->extra_info_buf, response->extra_info_buf,
> > + sizeof(struct fanotify_response_audit_rule));
>
> Since the fanotify_perm_event:extra_info_buf and
> fanotify_response:extra_info_buf are the same type/length, and they
> will be the same regardless of the extra_info_type field, why not
> simply get rid of the above switch statement and do something like
> this:
>
> memcpy(event->extra_info_buf, response->extra_info_buf,
> sizeof(response->extra_info_buf));
I've been wrestling with the possibility of doing a split between what
is presented to userspace and what's used in the kernel for struct
fanotify_response, while attempting to future-proof it.
At the moment, since the extra_info_buf is either zero or has a fixed
size for the "RULE" type, it seemed to be most efficient to do a static
allocation on the stack
Re: [PATCH v2 1/3] fanotify: Ensure consistent variable type for response
On 2022-05-02 20:16, Paul Moore wrote: > On Thu, Apr 28, 2022 at 8:45 PM Richard Guy Briggs wrote: > > > > The user space API for the response variable is __u32. This patch makes > > sure that the whole path through the kernel uses __u32 so that there is > > no sign extension or truncation of the user space response. > > > > Suggested-by: Steve Grubb > > Link: https://lore.kernel.org/r/12617626.uLZWGnKmhe@x2 > > Signed-off-by: Richard Guy Briggs > > Link: > > https://lore.kernel.org/r/aa98a3ad00666a6fc0ce411755de4a1a60f5c0cd.1651174324.git@redhat.com > > --- > > fs/notify/fanotify/fanotify.h | 2 +- > > fs/notify/fanotify/fanotify_user.c | 6 +++--- > > 2 files changed, 4 insertions(+), 4 deletions(-) > > It seems like audit_fanotify()/__audit_fanotify() should also be > changed, yes? Granted, in this case it's an unsigned int to u32 > conversion so not really all that critical, but if you are going to > update the fanotify code you might as well update the audit code as > well for the sake of completeness. Yes, that was somewhere in the back of my mind but forgot to come back to it. Thanks for catching that. > paul-moore.com - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- 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
On 2022-05-02 20:16, Paul Moore wrote:
> On Thu, Apr 28, 2022 at 8:55 PM 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?
>
> According to the git log, it came from Steve Grubb via de8cd83e91bc
> ("audit: Record fanotify access control decisions"). Steve should
> have known what he was doing with respect to field names so I'm
> assuming he had a reason.
>
> > 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="?
>
> Regardless of what it should have been, it is "resp" now and we can't
> really change it. As far as the field dictionary is concerned, while
> we should document these fields, it is important to note that when the
> dictionary conflicts with the kernel, the kernel wins by definition.
Agree on all counts. It was an open-ended question. It is also moot
since it is even expected in the audit-testsuite and would break that if
it were changed.
> > 2. It appears I'm ok changing the "__u32 response" to "__u16" without
> > breaking old userspace. Is this true on all arches?
>
> I can't answer that for you, the fanotify folks will need to look at
> that, but you likely already know that. While I haven't gone through
> the entire patchset yet, if it was me I probably would have left
> response as a u32 and just added the extra fields; you are already
> increasing the size of fanotify_response so why bother with shrinking
> an existing field?
I was thinking of that, but chose to follow the lead of the fanotify
mainainer.
> > 3. What should be the action if response contains unknown flags or
> > types? Is it reasonable to return -EINVAL?
>
> Once again, not a fanotify expert, but EINVAL is intended for invalid
> input so it seems like a reasonable choice.
The choice of the error code wasn't in question but rather the need to
fail rather than ignore unknown flags.
> > 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?
>
> If that is a concern, you should probably include a length field in
> the structure before the variable length field. You can't put it
> before fd or response, so it's really a question of before or after
> your new extra_info_type; I might suggest *after* extra_info_type, but
> that's just me.
After extra_info_type is what I was thinking. The other possibility is
that a type with a variable length field could define its data size as
the first field within the variable field as set out in the format of
that varible length field so that all the fixed length fields would not
need to waste that space or bandwidth.
Thanks for the feedback.
> paul-moore.com
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
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
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? 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="? 2. It appears I'm ok changing the "__u32 response" to "__u16" without breaking old userspace. Is this true on all arches? 3. What should be the action if response contains unknown flags or types? Is it reasonable to return -EINVAL? 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? > 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 > > Richard Guy Briggs (3): > fanotify: Ensure consistent variable type for response > fanotify: define struct members to hold response decision context > fanotify: Allow audit to use the full permission event response > > fs/notify/fanotify/fanotify.c | 5 ++- > fs/notify/fanotify/fanotify.h | 4 +- > fs/notify/fanotify/fanotify_user.c | 59 -- > include/linux/audit.h | 8 ++-- > include/linux/fanotify.h | 3 ++ > include/uapi/linux/fanotify.h | 27 +- > kernel/auditsc.c | 18 +++-- > 7 files changed, 94 insertions(+), 30 deletions(-) > > -- > 2.27.0 > - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v2 1/3] fanotify: Ensure consistent variable type for response
The user space API for the response variable is __u32. This patch makes
sure that the whole path through the kernel uses __u32 so that there is
no sign extension or truncation of the user space response.
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/12617626.uLZWGnKmhe@x2
Signed-off-by: Richard Guy Briggs
Link:
https://lore.kernel.org/r/aa98a3ad00666a6fc0ce411755de4a1a60f5c0cd.1651174324.git@redhat.com
---
fs/notify/fanotify/fanotify.h | 2 +-
fs/notify/fanotify/fanotify_user.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index a3d5b751cac5..70acfd497771 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -425,7 +425,7 @@ FANOTIFY_PE(struct fanotify_event *event)
struct fanotify_perm_event {
struct fanotify_event fae;
struct path path;
- unsigned short response;/* userspace answer to the event */
+ __u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
};
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index 9b32b76a9c30..694516470660 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -289,7 +289,7 @@ static int create_fd(struct fsnotify_group *group, struct
path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- unsigned int response)
+ __u32 response)
__releases(>notification_lock)
{
bool destroy = false;
@@ -310,9 +310,9 @@ static int process_access_response(struct fsnotify_group
*group,
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
- int response = response_struct->response;
+ __u32 response = response_struct->response;
- pr_debug("%s: group=%p fd=%d response=%d\n", __func__, group,
+ pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
fd, response);
/*
* make sure the response is valid, if invalid we do nothing and either
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v2 2/3] fanotify: define struct members to hold response decision context
This patch adds 2 structure members to the response 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 default is none. The patch defines one additional context
type which means that the second field is a 32-bit rule number. This
will allow for the creation of other context types in the future if
other users of the API identify different needs. The second field size
is defined by the context type and can be used to pass along the data
described by the context.
To support this, there is a macro for user space to check that the data
being sent is valid. Of course, without this check, anything that
overflows the bit field will trigger an EINVAL based on the use of
FAN_INVALID_RESPONSE_MASK in process_access_response().
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
Suggested-by: Jan Kara
Link: https://lore.kernel.org/r/20201001101219.ge17...@quack2.suse.cz
Signed-off-by: Richard Guy Briggs
Link:
https://lore.kernel.org/r/17660b3f2817e5c0a19d1e9e5d40b53ff4561845.1651174324.git@redhat.com
---
fs/notify/fanotify/fanotify.c | 1 -
fs/notify/fanotify/fanotify.h | 4 +-
fs/notify/fanotify/fanotify_user.c | 59 --
include/linux/fanotify.h | 3 ++
include/uapi/linux/fanotify.h | 27 +-
5 files changed, 72 insertions(+), 22 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 985e995d2a39..00aff6e29bf8 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -266,7 +266,6 @@ static int fanotify_get_response(struct fsnotify_group
*group,
case FAN_ALLOW:
ret = 0;
break;
- case FAN_DENY:
default:
ret = -EPERM;
}
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index 70acfd497771..87d643deabce 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -425,9 +425,11 @@ FANOTIFY_PE(struct fanotify_event *event)
struct fanotify_perm_event {
struct fanotify_event fae;
struct path path;
- __u32 response; /* userspace answer to the event */
+ __u16 response; /* userspace answer to the event */
+ __u16 extra_info_type;
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
+ char extra_info_buf[FANOTIFY_RESPONSE_EXTRA_LEN_MAX];
};
static inline struct fanotify_perm_event *
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index 694516470660..f1ff4cf683fb 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -289,13 +289,19 @@ static int create_fd(struct fsnotify_group *group, struct
path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- __u32 response)
+ struct fanotify_response *response)
__releases(>notification_lock)
{
bool destroy = false;
assert_spin_locked(>notification_lock);
- event->response = response;
+ event->response = response->response;
+ event->extra_info_type = response->extra_info_type;
+ switch (event->extra_info_type) {
+ case FAN_RESPONSE_INFO_AUDIT_RULE:
+ memcpy(event->extra_info_buf, response->extra_info_buf,
+ sizeof(struct fanotify_response_audit_rule));
+ }
if (event->state == FAN_EVENT_CANCELED)
destroy = true;
else
@@ -306,22 +312,29 @@ static void finish_permission_event(struct fsnotify_group
*group,
}
static int process_access_response(struct fsnotify_group *group,
- struct fanotify_response *response_struct)
+ struct fanotify_response *response_struct,
+ size_t count)
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
- __u32 response = response_struct->response;
+ __u16 response = response_struct->response;
- pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
-fd, response);
+ pr_debug("%s: group=%p fd=%d response=%u type=%u size=%lu\n", __func__,
+group, fd, response, response_struct->extra_info_type, count);
/*
* make sure the response is valid, if invalid we do nothing and either
* userspace can send a valid response or we will clean it up after the
* timeout
*/
- switch (respo
[PATCH v2 3/3] fanotify: Allow audit to use the full permission event response
This patch passes the full value 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. 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
Suggested-by: Steve Grubb
Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2
Signed-off-by: Richard Guy Briggs
Link:
https://lore.kernel.org/r/23c7f206a465d88cc646a944515fcc6a365f5eb2.1651174324.git@redhat.com
---
fs/notify/fanotify/fanotify.c | 4 +++-
include/linux/audit.h | 8
kernel/auditsc.c | 18 +++---
3 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 00aff6e29bf8..bb16d9e0f31b 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -272,7 +272,9 @@ 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,
+ event->extra_info_type,
+ (char *)>extra_info_buf);
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 d06134ac6245..0897128ee43b 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -419,7 +419,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(unsigned int response);
+extern void __audit_fanotify(__u16 response, __u16 type, char *buf);
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,
@@ -526,10 +526,10 @@ static inline void audit_log_kern_module(char *name)
__audit_log_kern_module(name);
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(__u16 response, __u16 type, char *buf)
{
if (!audit_dummy_context())
- __audit_fanotify(response);
+ __audit_fanotify(response, type, buf);
}
static inline void audit_tk_injoffset(struct timespec64 offset)
@@ -686,7 +686,7 @@ static inline void audit_log_kern_module(char *name)
{
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(__u16 response, __u16 type, char *buf)
{ }
static inline void audit_tk_injoffset(struct timespec64 offset)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index ea2ee1181921..afdbc416069a 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -64,6 +64,7 @@
#include
#include
#include // struct open_how
+#include
#include "audit.h"
@@ -2893,10 +2894,21 @@ void __audit_log_kern_module(char *name)
context->type = AUDIT_KERN_MODULE;
}
-void __audit_fanotify(unsigned int response)
+void __audit_fanotify(__u16 response, __u16 type, char *buf)
{
- audit_log(audit_context(), GFP_KERNEL,
- AUDIT_FANOTIFY, "resp=%u", response);
+ switch (type) {
+ case FAN_RESPONSE_INFO_AUDIT_RULE:
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=%u fan_ctx=%u",
+ response, type, (__u32)*buf);
+ break;
+ case FAN_RESPONSE_INFO_AUDIT_NONE:
+ default:
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=%u fan_ctx=?",
+ response, type);
+ break;
+ }
}
void __audit_tk_injoffset(struct timespec64 offset)
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v2 0/3] fanotify: Allow user space to pass back additional audit info
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 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 Richard Guy Briggs (3): fanotify: Ensure consistent variable type for response fanotify: define struct members to hold response decision context fanotify: Allow audit to use the full permission event response fs/notify/fanotify/fanotify.c | 5 ++- fs/notify/fanotify/fanotify.h | 4 +- fs/notify/fanotify/fanotify_user.c | 59 -- include/linux/audit.h | 8 ++-- include/linux/fanotify.h | 3 ++ include/uapi/linux/fanotify.h | 27 +- kernel/auditsc.c | 18 +++-- 7 files changed, 94 insertions(+), 30 deletions(-) -- 2.27.0 -- 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
On 2022-04-06 01:19, CGEL wrote: > On Mon, Apr 04, 2022 at 11:58:50AM -0400, Richard Guy Briggs wrote: > > On 2022-04-02 08:06, CGEL wrote: > > > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb wrote: > > > > > 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) ... > > > > > > > > That is exactly why I wrote the warning below in my response ... > > > > > > > I think the question is more clear now. > > > > > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > > > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > > > syscall with number 3000 are both invalid syscall. But 2000 can be set by > > > auditctl, and 3000 cannot be set by auditctl. > > > A better way to do this forbidden is to use > > > __NR_syscalls(asm-generic/unistd.h). > > > > > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid > > > syscall > > > See this patch. > > > > > > If we want audit invalid syscall as you said before. libaudit.c should not > > > do the forbidden, auditctl should allow setting syscall rule with 'any' > > > number. > > > So do you think we should fix libaudit.c? > > > > I'm having a bit of trouble understanding what you've said above. > > > > The kernel ultimately must protect itself from malice and mistakes, so > > it must verify all data sent to it. > > > > Userspace can help by knowing what that kernel policy is so it can avoid > > violating that policy or provide useful feedback if it can't. Userspace > > can be used to make things more efficient, but the kernel is the last > > step for security. > > > > If userspace and the kernel are mismatched or out of sync, then the > > kernel enforces policy to protect itself. > > Much appreciate for your interpretation. Have you get any idea of how > to solve the mismatched? From your viewpoint, I think it's better for > kernel to not handle syscall of syscall number<0, because it's invaild > of all arch, and has no value for attacker to probing for specific > syscall numbers. Going back to the very first quoted line above, if you can generate a test case that shows that audit is missing an auditable event, that is a bug that should be fixed. > > > > > > > to the audit syscall filter, which are unfortunately baked into > > > > > > > the > > > > > > > current design/implementation, which may affect this to some > > > > > > > extent. > > > > > > > > -- > > > > paul-moore.com > > > > - RGB - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- 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
On 2022-04-02 08:06, CGEL wrote: > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb wrote: > > > 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) ... > > > > That is exactly why I wrote the warning below in my response ... > > > I think the question is more clear now. > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > syscall with number 3000 are both invalid syscall. But 2000 can be set by > auditctl, and 3000 cannot be set by auditctl. > A better way to do this forbidden is to use > __NR_syscalls(asm-generic/unistd.h). > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > See this patch. > > If we want audit invalid syscall as you said before. libaudit.c should not > do the forbidden, auditctl should allow setting syscall rule with 'any' > number. > So do you think we should fix libaudit.c? I'm having a bit of trouble understanding what you've said above. The kernel ultimately must protect itself from malice and mistakes, so it must verify all data sent to it. Userspace can help by knowing what that kernel policy is so it can avoid violating that policy or provide useful feedback if it can't. Userspace can be used to make things more efficient, but the kernel is the last step for security. If userspace and the kernel are mismatched or out of sync, then the kernel enforces policy to protect itself. > > > > > 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. > > > > -- > > paul-moore.com - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v6] audit: log AUDIT_TIME_* records only from rules
On 2022-02-22 13:56, Paul Moore wrote:
> On Tue, Feb 22, 2022 at 11:45 AM Richard Guy Briggs wrote:
> > AUDIT_TIME_* events are generated when there are syscall rules present
> > that are not related to time keeping. This will produce noisy log
> > entries that could flood the logs and hide events we really care about.
> >
> > Rather than immediately produce the AUDIT_TIME_* records, store the data
> > in the context and log it at syscall exit time respecting the filter
> > rules.
> >
> > Note: This eats the audit_buffer, unlike any others in show_special().
> >
> > Please see https://bugzilla.redhat.com/show_bug.cgi?id=1991919
> >
> > Fixes: 7e8eda734d30 ("ntp: Audit NTP parameters adjustment")
> > Fixes: 2d87a0674bd6 ("timekeeping: Audit clock adjustments")
> > Signed-off-by: Richard Guy Briggs
> > ---
> > Changelog:
> > v2:
> > - rename __audit_ntp_log_ to audit_log_ntp
> > - pre-check ntp before storing
> > - move tk out of the context union and move ntp logging to the bottom of
> > audit_show_special()
> > - restructure logging of ntp to use ab and allocate more only if more
> > - add Fixes lines
> > v3
> > - move tk into union
> > - rename audit_log_ntp() to audit_log_time() and add tk
> > - key off both AUDIT_TIME_* but favour NTP
> > v4
> > - drop tk goto in favour of ntp if clause
> > - add comments to clarify calling function buffer expectations
> > v5
> > - hold my nose and swallow the audit_buffer in audit_log_time()
> > v6
> > - declare audit_log_time() and ntp_name as static
> >
> > kernel/audit.h | 4 +++
> > kernel/auditsc.c | 85
> > 2 files changed, 69 insertions(+), 20 deletions(-)
>
> Merged into audit/next.
Thank you.
> paul-moore.com
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v6] audit: log AUDIT_TIME_* records only from rules
AUDIT_TIME_* events are generated when there are syscall rules present
that are not related to time keeping. This will produce noisy log
entries that could flood the logs and hide events we really care about.
Rather than immediately produce the AUDIT_TIME_* records, store the data
in the context and log it at syscall exit time respecting the filter
rules.
Note: This eats the audit_buffer, unlike any others in show_special().
Please see https://bugzilla.redhat.com/show_bug.cgi?id=1991919
Fixes: 7e8eda734d30 ("ntp: Audit NTP parameters adjustment")
Fixes: 2d87a0674bd6 ("timekeeping: Audit clock adjustments")
Signed-off-by: Richard Guy Briggs
---
Changelog:
v2:
- rename __audit_ntp_log_ to audit_log_ntp
- pre-check ntp before storing
- move tk out of the context union and move ntp logging to the bottom of
audit_show_special()
- restructure logging of ntp to use ab and allocate more only if more
- add Fixes lines
v3
- move tk into union
- rename audit_log_ntp() to audit_log_time() and add tk
- key off both AUDIT_TIME_* but favour NTP
v4
- drop tk goto in favour of ntp if clause
- add comments to clarify calling function buffer expectations
v5
- hold my nose and swallow the audit_buffer in audit_log_time()
v6
- declare audit_log_time() and ntp_name as static
kernel/audit.h | 4 +++
kernel/auditsc.c | 85
2 files changed, 69 insertions(+), 20 deletions(-)
diff --git a/kernel/audit.h b/kernel/audit.h
index c4498090a5bd..58b66543b4d5 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -201,6 +201,10 @@ struct audit_context {
struct {
char*name;
} module;
+ struct {
+ struct audit_ntp_data ntp_data;
+ struct timespec64 tk_injoffset;
+ } time;
};
int fds[2];
struct audit_proctitle proctitle;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index fce5d43a933f..e928d94796e5 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1340,6 +1340,51 @@ static void audit_log_fcaps(struct audit_buffer *ab,
struct audit_names *name)
from_kuid(_user_ns, name->fcap.rootid));
}
+static void audit_log_time(struct audit_context *context, struct audit_buffer
**ab)
+{
+ const struct audit_ntp_data *ntp = >time.ntp_data;
+ const struct timespec64 *tk = >time.tk_injoffset;
+ static const char * const ntp_name[] = {
+ "offset",
+ "freq",
+ "status",
+ "tai",
+ "tick",
+ "adjust",
+ };
+ int type;
+
+ if (context->type == AUDIT_TIME_ADJNTPVAL) {
+ for (type = 0; type < AUDIT_NTP_NVALS; type++) {
+ if (ntp->vals[type].newval != ntp->vals[type].oldval) {
+ if (!*ab) {
+ *ab = audit_log_start(context,
GFP_KERNEL,
+
AUDIT_TIME_ADJNTPVAL);
+ if (!*ab)
+ return;
+ }
+ audit_log_format(*ab, "op=%s old=%lli new=%lli",
+ntp_name[type],
ntp->vals[type].oldval,
+ntp->vals[type].newval);
+ audit_log_end(*ab);
+ *ab = NULL;
+ }
+ }
+ }
+ if (tk->tv_sec != 0 || tk->tv_nsec != 0) {
+ if (!*ab) {
+ *ab = audit_log_start(context, GFP_KERNEL,
+ AUDIT_TIME_INJOFFSET);
+ if (!*ab)
+ return;
+ }
+ audit_log_format(*ab, "sec=%lli nsec=%li",
+(long long)tk->tv_sec, tk->tv_nsec);
+ audit_log_end(*ab);
+ *ab = NULL;
+ }
+}
+
static void show_special(struct audit_context *context, int *call_panic)
{
struct audit_buffer *ab;
@@ -1454,6 +1499,11 @@ static void show_special(struct audit_context *context,
int *call_panic)
audit_log_format(ab, "(null)");
break;
+ case AUDIT_TIME_ADJNTPVAL:
+ case AUDIT_TIME_INJOFFSET:
+ /* this call deviates from the rest, eating the buffer */
+ audit_log_time(context, );
+ break;
}
audit_log_end(ab);
}
@@ -2849,31 +2899,26 @@ void __audit_fanotify(unsigned int response)
void __audit_tk_injoffset(struct timespec64 offset)
{
- audit_log
[PATCH v5] audit: log AUDIT_TIME_* records only from rules
AUDIT_TIME_* events are generated when there are syscall rules present that are
not related to time keeping. This will produce noisy log entries that could
flood the logs and hide events we really care about.
Rather than immediately produce the AUDIT_TIME_* records, store the data in the
context and log it at syscall exit time respecting the filter rules.
Note: This eats the audit_buffer, unlike any others in show_special().
Please see https://bugzilla.redhat.com/show_bug.cgi?id=1991919
Fixes: 7e8eda734d30 ("ntp: Audit NTP parameters adjustment")
Fixes: 2d87a0674bd6 ("timekeeping: Audit clock adjustments")
Signed-off-by: Richard Guy Briggs
---
Changelog:
v2:
- rename __audit_ntp_log_ to audit_log_ntp
- pre-check ntp before storing
- move tk out of the context union and move ntp logging to the bottom of
audit_show_special()
- restructure logging of ntp to use ab and allocate more only if more
- add Fixes lines
v3
- move tk into union
- rename audit_log_ntp() to audit_log_time() and add tk
- key off both AUDIT_TIME_* but favour NTP
v4
- drop tk goto in favour of ntp if clause
- add comments to clarify calling function buffer expectations
v5
- hold my nose and swallow the audit_buffer in audit_log_time()
kernel/audit.h | 4 +++
kernel/auditsc.c | 85
2 files changed, 69 insertions(+), 20 deletions(-)
diff --git a/kernel/audit.h b/kernel/audit.h
index c4498090a5bd..58b66543b4d5 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -201,6 +201,10 @@ struct audit_context {
struct {
char*name;
} module;
+ struct {
+ struct audit_ntp_data ntp_data;
+ struct timespec64 tk_injoffset;
+ } time;
};
int fds[2];
struct audit_proctitle proctitle;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index fce5d43a933f..53d684966350 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1340,6 +1340,51 @@ static void audit_log_fcaps(struct audit_buffer *ab,
struct audit_names *name)
from_kuid(_user_ns, name->fcap.rootid));
}
+void audit_log_time(struct audit_context *context, struct audit_buffer **ab)
+{
+ const struct audit_ntp_data *ntp = >time.ntp_data;
+ const struct timespec64 *tk = >time.tk_injoffset;
+ const char *ntp_name[] = {
+ "offset",
+ "freq",
+ "status",
+ "tai",
+ "tick",
+ "adjust",
+ };
+ int type;
+
+ if (context->type == AUDIT_TIME_ADJNTPVAL) {
+ for (type = 0; type < AUDIT_NTP_NVALS; type++) {
+ if (ntp->vals[type].newval != ntp->vals[type].oldval) {
+ if (!*ab) {
+ *ab = audit_log_start(context,
GFP_KERNEL,
+
AUDIT_TIME_ADJNTPVAL);
+ if (!*ab)
+ return;
+ }
+ audit_log_format(*ab, "op=%s old=%lli new=%lli",
+ntp_name[type],
ntp->vals[type].oldval,
+ntp->vals[type].newval);
+ audit_log_end(*ab);
+ *ab = NULL;
+ }
+ }
+ }
+ if (tk->tv_sec != 0 || tk->tv_nsec != 0) {
+ if (!*ab) {
+ *ab = audit_log_start(context, GFP_KERNEL,
+ AUDIT_TIME_INJOFFSET);
+ if (!*ab)
+ return;
+ }
+ audit_log_format(*ab, "sec=%lli nsec=%li",
+(long long)tk->tv_sec, tk->tv_nsec);
+ audit_log_end(*ab);
+ *ab = NULL;
+ }
+}
+
static void show_special(struct audit_context *context, int *call_panic)
{
struct audit_buffer *ab;
@@ -1454,6 +1499,11 @@ static void show_special(struct audit_context *context,
int *call_panic)
audit_log_format(ab, "(null)");
break;
+ case AUDIT_TIME_ADJNTPVAL:
+ case AUDIT_TIME_INJOFFSET:
+ /* this call deviates from the rest, eating the buffer */
+ audit_log_time(context, );
+ break;
}
audit_log_end(ab);
}
@@ -2849,31 +2899,26 @@ void __audit_fanotify(unsigned int response)
void __audit_tk_injoffset(struct timespec64 offset)
{
- audit_log(audit_context(), GFP_KERNEL, AUDIT_TIME_INJOFFSET,
-
[PATCH v4] audit: log AUDIT_TIME_* records only from rules
AUDIT_TIME_* events are generated when there are syscall rules present that are
not related to time keeping. This will produce noisy log entries that could
flood the logs and hide events we really care about.
Rather than immediately produce the AUDIT_TIME_* records, store the data in the
context and log it at syscall exit time respecting the filter rules.
Please see https://bugzilla.redhat.com/show_bug.cgi?id=1991919
Fixes: 7e8eda734d30 ("ntp: Audit NTP parameters adjustment")
Fixes: 2d87a0674bd6 ("timekeeping: Audit clock adjustments")
Signed-off-by: Richard Guy Briggs
---
Changelog:
v2:
- rename __audit_ntp_log_ to audit_log_ntp
- pre-check ntp before storing
- move tk out of the context union and move ntp logging to the bottom of
audit_show_special()
- restructure logging of ntp to use ab and allocate more only if more
- add Fixes lines
v3
- move tk into union
- rename audit_log_ntp() to audit_log_time() and add tk
- key off both AUDIT_TIME_* but favour NTP
v4
- drop tk goto in favour of ntp if clause
- add comments to clarify calling function buffer expectations
kernel/audit.h | 4 +++
kernel/auditsc.c | 86 +---
2 files changed, 70 insertions(+), 20 deletions(-)
diff --git a/kernel/audit.h b/kernel/audit.h
index c4498090a5bd..58b66543b4d5 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -201,6 +201,10 @@ struct audit_context {
struct {
char*name;
} module;
+ struct {
+ struct audit_ntp_data ntp_data;
+ struct timespec64 tk_injoffset;
+ } time;
};
int fds[2];
struct audit_proctitle proctitle;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index fce5d43a933f..86f1c65ac933 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1340,6 +1340,53 @@ static void audit_log_fcaps(struct audit_buffer *ab,
struct audit_names *name)
from_kuid(_user_ns, name->fcap.rootid));
}
+void audit_log_time(struct audit_context *context, struct audit_buffer **ab)
+{
+ const struct audit_ntp_data *ntp = >time.ntp_data;
+ const struct timespec64 *tk = >time.tk_injoffset;
+ const char *ntp_name[] = {
+ "offset",
+ "freq",
+ "status",
+ "tai",
+ "tick",
+ "adjust",
+ };
+ /* use up allocated ab from show_special before new one */
+ int type, first = 1;
+
+ if (context->type == AUDIT_TIME_ADJNTPVAL) {
+ for (type = 0; type < AUDIT_NTP_NVALS; type++) {
+ if (ntp->vals[type].newval != ntp->vals[type].oldval) {
+ if (first) {
+ first = 0;
+ } else {
+ audit_log_end(*ab);
+ *ab = audit_log_start(context,
GFP_KERNEL,
+
AUDIT_TIME_ADJNTPVAL);
+ if (!*ab)
+ return;
+ }
+ audit_log_format(*ab, "op=%s old=%lli new=%lli",
+ntp_name[type],
ntp->vals[type].oldval,
+ntp->vals[type].newval);
+ }
+ }
+ }
+ if (tk->tv_sec != 0 || tk->tv_nsec != 0) {
+ if (!first) {
+ audit_log_end(*ab);
+ *ab = audit_log_start(context, GFP_KERNEL,
+ AUDIT_TIME_INJOFFSET);
+ if (!*ab)
+ return;
+ }
+ audit_log_format(*ab, "sec=%lli nsec=%li",
+(long long)tk->tv_sec, tk->tv_nsec);
+ }
+ /* allocated ab will be ended by show_special */
+}
+
static void show_special(struct audit_context *context, int *call_panic)
{
struct audit_buffer *ab;
@@ -1454,6 +1501,10 @@ static void show_special(struct audit_context *context,
int *call_panic)
audit_log_format(ab, "(null)");
break;
+ case AUDIT_TIME_ADJNTPVAL:
+ case AUDIT_TIME_INJOFFSET:
+ audit_log_time(context, );
+ break;
}
audit_log_end(ab);
}
@@ -2849,31 +2900,26 @@ void __audit_fanotify(unsigned int response)
void __audit_tk_injoffset(struct timespec64 offset)
{
- audit_log(audit_context(), GFP_KERNEL, AUDIT_TIME_INJOFFSET,
- "sec=%lli nsec=%li",
- (lo
Re: [PATCH v3] audit: log AUDIT_TIME_* records only from rules
On 2022-02-10 21:08, Paul Moore wrote:
> On Thu, Feb 10, 2022 at 6:46 PM Richard Guy Briggs wrote:
> > On 2022-01-31 20:29, Paul Moore wrote:
> > > On Mon, Jan 31, 2022 at 6:29 PM Richard Guy Briggs
> > > wrote:
> > > > On 2022-01-31 17:02, Paul Moore wrote:
> > > > > On Wed, Jan 26, 2022 at 8:52 AM Richard Guy Briggs
> > > > > wrote:
> > > > > > On 2022-01-25 22:24, Richard Guy Briggs wrote:
>
> This isn't as complete of a response as I would like, but I wanted to
> get *something* back to you same-day since the delays are getting a
> bit long ...
>
> > > > > [WARNING: not compiled, tested, yadda yadda]
> > > > >
> > > > > void audit_log_time(struct audit_context ctx, struct audit_buffer
> > > > > **abp)
> > > > > {
> > > > > int i;
> > > > > int type = ctx->type;
> > > > > struct audit_buffer *ab = *abp;
> > > > > struct audit_ntp_val *ntp;
> > > > > const struct timespec64 *tk;
> > > > > const char *ntp_name[] = {
> > > > > "offset",
> > > > > "freq",
> > > > > "status",
> > > > > "tai",
> > > > > "tick",
> > > > > "adjust",
> > > > > };
> > > > >
> > > > > do {
> > > > > if (type == AUDIT_TIME_ADJNTPVAL) {
> > > > > ntp = ctx->time.ntp_data.val;
> > > > > for (i = 0; i < AUDIT_NTP_NVALS; i++) {
> > > > > if (ntp[i].newval != ntp[i].oldval) {
> > > > > audit_log_format(ab,
> > > > > "op=%s old=%lli new=%lli",
> > > > > ntp_name[type],
> > > > > ntp[i].oldval, ntp[i].newval);
> > > > > }
> > > > > }
> > > > > } else {
> > > > > tk = >time.tk_injoffset;
> > > > > audit_log_format(ab, "sec=%lli nsec=%li",
> > > > > (long long)tk->tv_sec, tk->tv_nsec);
> > > > > }
> > > > > audit_log_end(ab);
> > > >
> > > > There is an audit_log_end() in the calling function, show_special(), so
> > > > it should only be called here if there is another buffer allocated in
> > > > this function after it. audit_log_end() is protected should it be
> > > > called with no valid buffer so this wouldn't create a bug.
> > >
> > > As audit_log_end() can safely take a NULL audit_buffer I don't care if we
> > > send it back a valid buffer or a NULL. IMO it happens to be easier (and
> > > cleaner) to send back a NULL.
> >
> > None of the other callees in show_special() do that, so this would be
> > surprising behaviour that could cause a future bug ...
>
> To be both honest and frank: I disagree with your assessment. If you
> really want to be concerned about this, there are plenty of ways to
> mitigate the "risk" depending on your comfort level; comments and
> returning within the switch/case block are just some of the options.
>
> > > > > if (*abp) {
> > > > > *abp = NULL;
> > > > > type = (type == AUDIT_TIME_ADJNTPVAL ?
> > > > > AUDIT_TIME_INJOFFSET : AUDIT_TIME_ADJNTPVAL);
> > > >
> > > > This cannot be allocated if there are no more needed above ...
> > >
> > > My mistake, I was distracted a few times while typing up my reply and the
> > > code within; while I had that detail in mind when I started I lost it
> > > during one of the interruptions. As penance, I wrote up some slightly
> > > more
> > > proper code and at least made sure it complied, although I've not tried
> > > booting it ...
> >
> > Did you test the code I submitted? It compiles and works. I found this
> > code harder to follow. This was partly why I wanted to leave one of the
> > record types outside of show_special() but I did find a way to
> > accomodate both with a minimum of overhead.
>
> Once again, I disagree with your assessment of the code. I'm not sure
> how to put this politely, but I personally found your audit_log_time()
> implementation to be awkward; the AUDIT_TIME_INJOFFSET goto/jump to
> "tk" at the top of the function was not something I'm going to merge.
> You don't have to like my suggestion, but please send me a patch that
> has a somewhat reasonable code flow. I know you often want, or at
> least ask for explicit suggestions (hence my untested code example),
> but since you didn't like that let me just say this: when in doubt,
> limit your use of gotos/jumps to error handling unless there is
> something significantly unusual about the function. In my opinion
> there is nothing significantly unusual about the audit_log_time()
> function to require a jump as you've currently done.
I hate gotos. I first learned to program on Waterloo Structured BASIC
4.0 on a Commodore PET 2001 where the language structure provided the
tools to be able to avoid them. I've avoided them and reluctantly used
them at your urging, so now I'm a bit confused.
> paul-moore.com
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v3] audit: log AUDIT_TIME_* records only from rules
On 2022-01-31 20:29, Paul Moore wrote:
> On Mon, Jan 31, 2022 at 6:29 PM Richard Guy Briggs wrote:
> > On 2022-01-31 17:02, Paul Moore wrote:
> > > On Wed, Jan 26, 2022 at 8:52 AM Richard Guy Briggs
> > > wrote:
> > > > On 2022-01-25 22:24, Richard Guy Briggs wrote:
> > > > > AUDIT_TIME_* events are generated when there are syscall rules
> > > > > present that are
> > > > > not related to time keeping. This will produce noisy log entries
> > > > > that could
> > > > > flood the logs and hide events we really care about.
> > > > >
> > > > > Rather than immediately produce the AUDIT_TIME_* records, store the
> > > > > data in the
> > > > > context and log it at syscall exit time respecting the filter rules.
> > > > >
> > > > > Please see https://bugzilla.redhat.com/show_bug.cgi?id=1991919
> > > > >
> > > > > Fixes: 7e8eda734d30 ("ntp: Audit NTP parameters adjustment")
> > > > > Fixes: 2d87a0674bd6 ("timekeeping: Audit clock adjustments")
> > > > > Signed-off-by: Richard Guy Briggs
> > > > > ---
> > > > > Changelog:
> > > > > v2:
> > > > > - rename __audit_ntp_log_ to audit_log_ntp
> > > > > - pre-check ntp before storing
> > > > > - move tk out of the context union and move ntp logging to the bottom
> > > > > of audit_show_special()
> > > > > - restructure logging of ntp to use ab and allocate more only if more
> > > > > - add Fixes lines
> > > > > v3
> > > > > - move tk into union
> > > > > - rename audit_log_ntp() to audit_log_time() and add tk
> > > > > - key off both AUDIT_TIME_* but favour NTP
> > > > >
> > > > > kernel/audit.h | 4 +++
> > > > > kernel/auditsc.c | 86
> > > > > +---
> > > > > 2 files changed, 70 insertions(+), 20 deletions(-)
> > >
> > > ...
> > >
> > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > > index b517947bfa48..9c6c55a81fdb 100644
> > > > > --- a/kernel/auditsc.c
> > > > > +++ b/kernel/auditsc.c
> > > > > @@ -1331,6 +1331,55 @@ static void audit_log_fcaps(struct
> > > > > audit_buffer *ab, struct audit_names *name)
> > > > >from_kuid(_user_ns, name->fcap.rootid));
> > > > > }
> > > > >
> > > > > +void audit_log_time(struct audit_context *context, struct
> > > > > audit_buffer **ab)
> > > > > +{
> > > > > + const struct audit_ntp_data *ntp = >time.ntp_data;
> > > > > + const struct timespec64 *tk = >time.tk_injoffset;
> > > > > + const char *ntp_name[] = {
> > > > > + "offset",
> > > > > + "freq",
> > > > > + "status",
> > > > > + "tai",
> > > > > + "tick",
> > > > > + "adjust",
> > > > > + };
> > > > > + int type, first = 1;
> > > > > +
> > > > > + if (context->type == AUDIT_TIME_INJOFFSET)
> > > > > + goto tk;
> > > > > +
> > > > > + /* use up allocated ab from show_special before new one */
> > > > > + for (type = 0; type < AUDIT_NTP_NVALS; type++) {
> > > > > + if (ntp->vals[type].newval != ntp->vals[type].oldval) {
> > > > > + if (first) {
> > > > > + first = 0;
> > > > > + } else {
> > > > > + audit_log_end(*ab);
> > > > > + *ab = audit_log_start(context,
> > > > > GFP_KERNEL,
> > > > > +
> > > > > AUDIT_TIME_ADJNTPVAL);
> > > > > + if (!*ab)
> > > > > + return;
> > > > > + }
> > > > > + audit_log_format(*ab, "op=%s old=%lli new=%lli",
> > > > > +
Re: [PATCH v4 2/3] audit: add support for the openat2 syscall
On 2022-02-09 16:18, Paul Moore wrote:
> On Wed, Feb 9, 2022 at 10:57 AM Paul Moore wrote:
> > On Tue, Feb 8, 2022 at 10:44 PM Jeff Mahoney wrote:
> > >
> > > Hi Richard -
> > >
> > > On 5/19/21 16:00, Richard Guy Briggs wrote:
> > > > The openat2(2) syscall was added in kernel v5.6 with commit fddb5d430ad9
> > > > ("open: introduce openat2(2) syscall")
> > > >
> > > > Add the openat2(2) syscall to the audit syscall classifier.
> > > >
> > > > Link: https://github.com/linux-audit/audit-kernel/issues/67
> > > > Signed-off-by: Richard Guy Briggs
> > > > Link:
> > > > https://lore.kernel.org/r/f5f1a4d8699613f8c02ce762807228c841c2e26f.1621363275.git@redhat.com
> > > > ---
> > >
> > > [...]
> > >
> > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > index d775ea16505b..3f59ab209dfd 100644
> > > > --- a/kernel/auditsc.c
> > > > +++ b/kernel/auditsc.c
> > > > @@ -76,6 +76,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > #include "audit.h"
> > > >
> > > > @@ -196,6 +197,8 @@ static int audit_match_perm(struct audit_context
> > > > *ctx, int mask)
> > > > return ((mask & AUDIT_PERM_WRITE) && ctx->argv[0] ==
> > > > SYS_BIND);
> > > > case AUDITSC_EXECVE:
> > > > return mask & AUDIT_PERM_EXEC;
> > > > + case AUDITSC_OPENAT2:
> > > > + return mask & ACC_MODE((u32)((struct open_how
> > > > *)ctx->argv[2])->flags);
> > > > default:
> > > > return 0;
> > > > }
> > >
> > > ctx->argv[2] holds a userspace pointer and can't be dereferenced like
> > > this.
> > >
> > > I'm getting oopses, like so:
> > > BUG: unable to handle page fault for address: 7fff961bbe70
> >
> > Thanks Jeff.
> >
> > Yes, this is obviously the wrong thing to being doing; I remember
> > checking to make sure we placed the audit_openat2_how() hook after the
> > open_how was copied from userspace, but I missed the argv dereference
> > in the syscall exit path when reviewing the code.
> >
> > Richard, as we are already copying the open_how info into
> > audit_context::openat2 safely, the obvious fix is to convert
> > audit_match_perm() to use the previously copied value instead of argv.
> > If you can't submit a patch for this today please let me know.
>
> I haven't heard anything from Richard so I put together a patch which
> should fix the problem (link below). It's currently untested, but
> I've got a kernel building now with the patch ...
Well, the day wasn't over yet... I've compiled and tested it.
> https://lore.kernel.org/linux-audit/16111699.153511.15656610495968926251.stgit@olly/T/#u
>
> --
> paul-moore.com
>
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v1] audit: fix illegal pointer dereference for openat2
The user pointer was being illegally dereferenced directly to get the
open_how flags data in audit_match_perm. Use the previously saved flags
data elsewhere in the context instead.
Coverage is provided by the audit-testsuite syscalls_file test case.
Cc: sta...@vger.kernel.org
Link: https://lore.kernel.org/r/c96031b4-b76d-d82c-e232-1cccbbf71...@suse.com
Fixes: 1c30e3af8a79 ("audit: add support for the openat2 syscall")
Reported-by: Jeff Mahoney
Signed-off-by: Richard Guy Briggs
---
kernel/auditsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index fce5d43a933f..81ab510a7be4 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -185,7 +185,7 @@ static int audit_match_perm(struct audit_context *ctx, int
mask)
case AUDITSC_EXECVE:
return mask & AUDIT_PERM_EXEC;
case AUDITSC_OPENAT2:
- return mask & ACC_MODE((u32)((struct open_how
*)ctx->argv[2])->flags);
+ return mask & ACC_MODE((u32)(ctx->openat2.flags));
default:
return 0;
}
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v4 2/3] audit: add support for the openat2 syscall
On 2022-02-09 10:57, Paul Moore wrote:
> On Tue, Feb 8, 2022 at 10:44 PM Jeff Mahoney wrote:
> >
> > Hi Richard -
> >
> > On 5/19/21 16:00, Richard Guy Briggs wrote:
> > > The openat2(2) syscall was added in kernel v5.6 with commit fddb5d430ad9
> > > ("open: introduce openat2(2) syscall")
> > >
> > > Add the openat2(2) syscall to the audit syscall classifier.
> > >
> > > Link: https://github.com/linux-audit/audit-kernel/issues/67
> > > Signed-off-by: Richard Guy Briggs
> > > Link:
> > > https://lore.kernel.org/r/f5f1a4d8699613f8c02ce762807228c841c2e26f.1621363275.git@redhat.com
> > > ---
> >
> > [...]
> >
> > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > index d775ea16505b..3f59ab209dfd 100644
> > > --- a/kernel/auditsc.c
> > > +++ b/kernel/auditsc.c
> > > @@ -76,6 +76,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include "audit.h"
> > >
> > > @@ -196,6 +197,8 @@ static int audit_match_perm(struct audit_context
> > > *ctx, int mask)
> > > return ((mask & AUDIT_PERM_WRITE) && ctx->argv[0] ==
> > > SYS_BIND);
> > > case AUDITSC_EXECVE:
> > > return mask & AUDIT_PERM_EXEC;
> > > + case AUDITSC_OPENAT2:
> > > + return mask & ACC_MODE((u32)((struct open_how
> > > *)ctx->argv[2])->flags);
> > > default:
> > > return 0;
> > > }
> >
> > ctx->argv[2] holds a userspace pointer and can't be dereferenced like this.
> >
> > I'm getting oopses, like so:
> > BUG: unable to handle page fault for address: 7fff961bbe70
>
> Thanks Jeff.
>
> Yes, this is obviously the wrong thing to being doing; I remember
> checking to make sure we placed the audit_openat2_how() hook after the
> open_how was copied from userspace, but I missed the argv dereference
> in the syscall exit path when reviewing the code.
>
> Richard, as we are already copying the open_how info into
> audit_context::openat2 safely, the obvious fix is to convert
> audit_match_perm() to use the previously copied value instead of argv.
> If you can't submit a patch for this today please let me know.
Agreed. It would have been more awkward with the original order of the
patches.
The syscalls_file test in the audit-testsuite should have caught this.
https://github.com/rgbriggs/audit-testsuite/commit/1c99021ae27ea23eccce2bb1861df4c9c665cd5b
The test provided does essentially the same thing.
I should have a tested patch posted today.
> paul-moore.com
- RGB
--
Richard Guy Briggs
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: How to configure auditd to register like internal bash commands?
On 2022-02-07 23:37, André Letterer wrote: >Hi folks, > >I would like to have some help on configuring auditd for very short >running commands like >unset ... >set ... >export ... >history -c > >or similar commands. >How would that be possible? >Would you mind please to help me on some knowledge about that? You may want to look into pam_tty_audit, but it may flood your logs. - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v3] audit: log AUDIT_TIME_* records only from rules
On 2022-01-31 17:02, Paul Moore wrote:
> On Wed, Jan 26, 2022 at 8:52 AM Richard Guy Briggs wrote:
> > On 2022-01-25 22:24, Richard Guy Briggs wrote:
> > > AUDIT_TIME_* events are generated when there are syscall rules present
> > > that are
> > > not related to time keeping. This will produce noisy log entries that
> > > could
> > > flood the logs and hide events we really care about.
> > >
> > > Rather than immediately produce the AUDIT_TIME_* records, store the data
> > > in the
> > > context and log it at syscall exit time respecting the filter rules.
> > >
> > > Please see https://bugzilla.redhat.com/show_bug.cgi?id=1991919
> > >
> > > Fixes: 7e8eda734d30 ("ntp: Audit NTP parameters adjustment")
> > > Fixes: 2d87a0674bd6 ("timekeeping: Audit clock adjustments")
> > > Signed-off-by: Richard Guy Briggs
> > > ---
> > > Changelog:
> > > v2:
> > > - rename __audit_ntp_log_ to audit_log_ntp
> > > - pre-check ntp before storing
> > > - move tk out of the context union and move ntp logging to the bottom of
> > > audit_show_special()
> > > - restructure logging of ntp to use ab and allocate more only if more
> > > - add Fixes lines
> > > v3
> > > - move tk into union
> > > - rename audit_log_ntp() to audit_log_time() and add tk
> > > - key off both AUDIT_TIME_* but favour NTP
> > >
> > > kernel/audit.h | 4 +++
> > > kernel/auditsc.c | 86 +---
> > > 2 files changed, 70 insertions(+), 20 deletions(-)
>
> ...
>
> > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > index b517947bfa48..9c6c55a81fdb 100644
> > > --- a/kernel/auditsc.c
> > > +++ b/kernel/auditsc.c
> > > @@ -1331,6 +1331,55 @@ static void audit_log_fcaps(struct audit_buffer
> > > *ab, struct audit_names *name)
> > >from_kuid(_user_ns, name->fcap.rootid));
> > > }
> > >
> > > +void audit_log_time(struct audit_context *context, struct audit_buffer
> > > **ab)
> > > +{
> > > + const struct audit_ntp_data *ntp = >time.ntp_data;
> > > + const struct timespec64 *tk = >time.tk_injoffset;
> > > + const char *ntp_name[] = {
> > > + "offset",
> > > + "freq",
> > > + "status",
> > > + "tai",
> > > + "tick",
> > > + "adjust",
> > > + };
> > > + int type, first = 1;
> > > +
> > > + if (context->type == AUDIT_TIME_INJOFFSET)
> > > + goto tk;
> > > +
> > > + /* use up allocated ab from show_special before new one */
> > > + for (type = 0; type < AUDIT_NTP_NVALS; type++) {
> > > + if (ntp->vals[type].newval != ntp->vals[type].oldval) {
> > > + if (first) {
> > > + first = 0;
> > > + } else {
> > > + audit_log_end(*ab);
> > > + *ab = audit_log_start(context, GFP_KERNEL,
> > > + AUDIT_TIME_ADJNTPVAL);
> > > + if (!*ab)
> > > + return;
> > > + }
> > > + audit_log_format(*ab, "op=%s old=%lli new=%lli",
> > > + ntp_name[type],
> > > ntp->vals[type].oldval,
> > > + ntp->vals[type].newval);
> > > + }
> > > + }
> > > +
> > > +tk:
> > > + if (tk->tv_sec != 0 || tk->tv_nsec != 0) {
> > > + if (!first) {
> > > + audit_log_end(*ab);
> > > + *ab = audit_log_start(context, GFP_KERNEL,
> > > + AUDIT_TIME_INJOFFSET);
> > > + if (!*ab)
> > > + return;
> > > + }
> >
> > It occurs to me that a slight improvement could be made to move the
> > "tk:" label here. And better yet, change the tk condition above to:
> >
> > if (!tk->tv_sec && !tk->tv_nsec)
> >
Re: [PATCH v3] audit: log AUDIT_TIME_* records only from rules
On 2022-01-25 22:24, Richard Guy Briggs wrote:
> AUDIT_TIME_* events are generated when there are syscall rules present that
> are
> not related to time keeping. This will produce noisy log entries that could
> flood the logs and hide events we really care about.
>
> Rather than immediately produce the AUDIT_TIME_* records, store the data in
> the
> context and log it at syscall exit time respecting the filter rules.
>
> Please see https://bugzilla.redhat.com/show_bug.cgi?id=1991919
>
> Fixes: 7e8eda734d30 ("ntp: Audit NTP parameters adjustment")
> Fixes: 2d87a0674bd6 ("timekeeping: Audit clock adjustments")
> Signed-off-by: Richard Guy Briggs
> ---
> Changelog:
> v2:
> - rename __audit_ntp_log_ to audit_log_ntp
> - pre-check ntp before storing
> - move tk out of the context union and move ntp logging to the bottom of
> audit_show_special()
> - restructure logging of ntp to use ab and allocate more only if more
> - add Fixes lines
> v3
> - move tk into union
> - rename audit_log_ntp() to audit_log_time() and add tk
> - key off both AUDIT_TIME_* but favour NTP
>
> kernel/audit.h | 4 +++
> kernel/auditsc.c | 86 +---
> 2 files changed, 70 insertions(+), 20 deletions(-)
>
> diff --git a/kernel/audit.h b/kernel/audit.h
> index c4498090a5bd..58b66543b4d5 100644
> --- a/kernel/audit.h
> +++ b/kernel/audit.h
> @@ -201,6 +201,10 @@ struct audit_context {
> struct {
> char*name;
> } module;
> + struct {
> + struct audit_ntp_data ntp_data;
> + struct timespec64 tk_injoffset;
> + } time;
> };
> int fds[2];
> struct audit_proctitle proctitle;
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index b517947bfa48..9c6c55a81fdb 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -1331,6 +1331,55 @@ static void audit_log_fcaps(struct audit_buffer *ab,
> struct audit_names *name)
>from_kuid(_user_ns, name->fcap.rootid));
> }
>
> +void audit_log_time(struct audit_context *context, struct audit_buffer **ab)
> +{
> + const struct audit_ntp_data *ntp = >time.ntp_data;
> + const struct timespec64 *tk = >time.tk_injoffset;
> + const char *ntp_name[] = {
> + "offset",
> + "freq",
> + "status",
> + "tai",
> + "tick",
> + "adjust",
> + };
> + int type, first = 1;
> +
> + if (context->type == AUDIT_TIME_INJOFFSET)
> + goto tk;
> +
> + /* use up allocated ab from show_special before new one */
> + for (type = 0; type < AUDIT_NTP_NVALS; type++) {
> + if (ntp->vals[type].newval != ntp->vals[type].oldval) {
> + if (first) {
> + first = 0;
> + } else {
> + audit_log_end(*ab);
> + *ab = audit_log_start(context, GFP_KERNEL,
> + AUDIT_TIME_ADJNTPVAL);
> + if (!*ab)
> + return;
> + }
> + audit_log_format(*ab, "op=%s old=%lli new=%lli",
> + ntp_name[type], ntp->vals[type].oldval,
> + ntp->vals[type].newval);
> + }
> + }
> +
> +tk:
> + if (tk->tv_sec != 0 || tk->tv_nsec != 0) {
> + if (!first) {
> + audit_log_end(*ab);
> + *ab = audit_log_start(context, GFP_KERNEL,
> + AUDIT_TIME_INJOFFSET);
> + if (!*ab)
> + return;
> + }
It occurs to me that a slight improvement could be made to move the
"tk:" label here. And better yet, change the tk condition above to:
if (!tk->tv_sec && !tk->tv_nsec)
return;
> + audit_log_format(*ab, "sec=%lli nsec=%li",
> + (long long)tk->tv_sec, tk->tv_nsec);
> + }
> +}
> +
> static void show_special(struct audit_context *context, int *call_panic)
> {
> struct audit_buffer *ab;
> @@ -1445,6 +1494,10 @@ static void show_special(struct audit_context
> *context, int *call_panic)
> audit_log_format(ab, "(null)");
