Re: [viro@zeniv.linux.org.uk: [RFC] audit reporting (or not
reporting) pathnames on early failures in syscalls]
by Richard Guy Briggs
On 2025-10-31 08:06, Al Viro wrote:
> OK, that's two misspellings of the list name already;-/
Adding the audit userspace list to get Steve Grubb's certification take on this.
> Al, deeply embarrassed and crawling to get some sleep...
>
> ----- Forwarded message from Al Viro <viro(a)zeniv.linux.org.uk> -----
>
> Date: Fri, 31 Oct 2025 07:58:56 +0000
> From: Al Viro <viro(a)zeniv.linux.org.uk>
> To: linux-audit(a)vger.kernel.org
> Cc: Linus Torvalds <torvalds(a)linux-foundation.org>, linux-fsdevel(a)vger.kernel.org, Paul Moore <paul(a)paul-moore.com>
> Subject: [RFC] audit reporting (or not reporting) pathnames on early failures in syscalls
>
> FWIW, I've just noticed that a patch in the series I'd been
> reordering had the following chunk:
> @@ -1421,20 +1421,16 @@ static int do_sys_openat2(int dfd, const char __user *filename,
> struct open_how *how)
> {
> struct open_flags op;
> - struct filename *tmp;
> int err, fd;
>
> err = build_open_flags(how, &op);
> if (unlikely(err))
> return err;
>
> - tmp = getname(filename);
> - if (IS_ERR(tmp))
> - return PTR_ERR(tmp);
> -
> fd = get_unused_fd_flags(how->flags);
> if (likely(fd >= 0)) {
> - struct file *f = do_filp_open(dfd, tmp, &op);
> + struct filename *name __free(putname) = getname(filename);
> + struct file *f = do_filp_open(dfd, name, &op);
> if (IS_ERR(f)) {
> put_unused_fd(fd);
> fd = PTR_ERR(f);
>
> From the VFS or userland POV there's no problem - we would get a
> different error reported e.g. in case when *both* EMFILE and ENAMETOOLONG
> would be applicable, but that's perfectly fine. However, from the audit
> POV it changes behaviour.
>
> Consider behaviour of openat2(2).
> 1. we do sanity checks on the last ('usize') argument. If they
> fail, we are done.
> 2. we copy struct open_how from userland ('how' argument).
> If copyin fails, we are done.
> 3. we do sanity checks on how->flags, how->resolve and how->mode.
> If they fail, we are done.
> 4. we copy the pathname to be opened from userland ('filename' argument).
> If that fails, or if the pathname is either empty or too long, we are done.
> 5. we reserve an unused file descriptor. If that fails, we are done.
> 6. we allocate an empty struct file. If that fails, we are done.
> 7. we finally get around to the business - finding and opening the damn thing.
> Which also can fail, of course.
>
> We are expected to be able to produce a record of failing
> syscall. If we fail on step 4, well, the lack of pathname to come with
> the record is to be expected - we have failed to get it, after all.
> The same goes for failures on steps 1..3 - we hadn't gotten around to
> looking at the pathname yet, so there's no pathname to report. What (if
> anything) makes "insane how->flags" different from "we have too many
> descriptors opened already"? The contents of the pathname is equally
> irrelevant in both cases. Yet in the latter case (failure at step 5)
> the pathname would get reported. Do we need to preserve that behaviour?
>
> Because the patch quoted above would change it. It puts the failure
> to allocate a descriptor into the same situation as failures on steps 1..3.
>
> As far as I can see, there are three possible approaches:
>
> 1) if the current kernel imports the pathname before some check, that shall
> always remain that way, no matter what. Audit might be happy, but nobody
> else would - we'll need to document that constraint and watch out for such
> regressions. And I'm pretty sure that over the years there had been
> other such changes that went into mainline unnoticed.
>
> 2) reordering is acceptable. Of course, the pathname import must happen
> before we start using it, but that's the only real constraint. That would
> mean the least headache for everyone other than audit folks.
>
> 3) import the pathnames as early as possible. It would mean a non-trivial
> amount of churn, but it's at least a definite policy - validity of change
> depends only on the resulting code, not the comparison with the earlier
> state, as it would in case (1). From QoI POV it's as nice as audit folks
> could possibly ask, but it would cause quite a bit of churn to get there.
> Not impossible to do, but I would rather not go there without a need.
> Said that, struct filename handling is mostly a decent match to CLASS()
> machinery, and all required churn wouldn't be hard to fold into conversion
> to that.
>
> My preference would be (2), obviously. However, it really depends
> upon the kind of requirements audit users have. Note that currently the
> position of pathname import in the sequence is not documented anywhere,
> so there's not much audit users can rely upon other than "the current
> behaviour is such-and-such, let's hope it doesn't change"... ;-/
>
> Comments?
>
>
> ----- End forwarded message -----
>
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
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
2 months
Re: libaudit: android support
by William Roberts
On Wed, Oct 15, 2025, 09:15 Jean-Jacques Pitrolle <
jean-jacques.pitrolle(a)sysgo.com> wrote:
> Hi,
> I don't know if you forget to add the list as CC so i answer you
> directly and send it to the list if you are okay.
>
Oops, yeah all re-add the list.
>
> On 14/10/2025 19:52, William Roberts wrote:
> > On Tue, Oct 14, 2025 at 12:09 PM Jean-Jacques Pitrolle
> > <jean-jacques.pitrolle(a)sysgo.com> wrote:
> >>
> >> Hi Bill
> >>
> >> On 14/10/2025 18:54, William Roberts wrote:
> >>> I did a rewrite of libaudit for Android and it was merged into logd.
> >>> It's been a long time since I have looked at it,
> >>> but AFAIK, the logs should be available via logcat. None of this will
> >>> be part of the ndk if you want to build against it,
> >>> it's really a system only level thing.
> >>>
> >>> Here is where that libaudit code lives now:
> >>>
> https://cs.android.com/android/platform/superproject/main/+/main:system/
> >>> logging/logd/libaudit/libaudit.cpp
> >>
> >> Thanks for your quick answer.
> >>
> >> Okay at least something exists for libaudit. I need to take a look on it
> >> to see how i can use it.
> >
> > Ultimately you need permissions to the netlink socket that the audit
> > subsystem uses,
> > and that is not available to typical android applications, you would
> > need to build your
> > own custom Android that exposes that. However, that would violate the
> > required CTS
> > for Android branding IIRC.
>
> I think at the end it is a *problem* to build my own Android to access
> the netlink socket.
> My purpose is to stick as much as possible to a vanilla Android: so
> avoid as much as possible specific modification.
>
Yeah so you want to write an application for Android.
>
> >
> >>
> >> And what about libauparse?
> >
> > I don't believe that is there.
> >
> >> Should i consider to build it myself with Android build environment?
> >
> > You can grab and build anything, code is code, but the biggest part of
> > the way Android containers
> > work is, "Will I have permissions to get at the resource". If you just
> > want to look at the messages,
> > it's in logcat, and you can build an application that has the
> > permission READ_LOGS IIRC, in the
> > Android Manifest to look at logcat and then look for selinux/audit
> messages.
>
> Hmm i'm not very familiar with Android execution environment.
> I want to create a C/C++ application (not Kotlin/Java..) an i don't know
> if a manifest is required.
> I need to do my 'Android architecture' homework before to have a clear
> understanding of the pre-requisite for my use case.
>
Yeah this jargon is just part of the steps to create an application. Just a
quick
look, there is an open source Android logcat reader application:
- https://github.com/darshanparajuli/LogcatReader
You could probably just modify that.
I believe the Android NDK allows pure native applications, but ultimately
in Android now,
even Java/Kotlin gets reduced to native ELF binaries through OAT which is a
play on AOT
which is Ahead of Time Compilation. Essentially the byte code gets
translated into a shared
library loaded up by a framework and executed IIUC/IIRC.
I would recommend just using Kotlin because of the support, and you can
call any native
functions, like things from libauparse, from Kotlin. When I used to Android
it was all Java
and JNI, I would imagine it's essentially JNI for Kotlin too, but don't
quote me.
> >
> > More about your ultimate goal would help me understand and formulate a
> > better response if you
> > can share that?
>
> My ultimate goal is to read audit/log events from various daemons like
> auditd, syslogd, .. and transform those events to a format closed to
> Qualified Security Event defined by AUTOSAR[1].
> On a GNU/Linux distribution the services are "well" defined and known
> (at least by myself ^^)
> On an Android it seems that *everything* is logged by logd/logcat.
>
Yeah logcat is the central logger, so create an application that listens to
logcat, then look for
the events you care about and reformat them as needed calling libauparse.
>
> Thanks.
> Regards
>
> [1]:
>
> https://www.autosar.org/fileadmin/standards/R22-11/FO/AUTOSAR_PRS_Intrusi...>
>
>
> >>
> >> Regards.
>
2 months, 2 weeks
libaudit: android support
by Jean-Jacques Pitrolle
Hi list,
My concern is pretty simple: does audit userspace infrastructure
available for *Android*?
It seems not with the following components (installed through sdkmanager):
- build-tools: 36.0.0-rc3
- ndk: 27.2.12479018
- cmake: 3.31.1
Thanks.
Regards.
2 months, 3 weeks
libauparse: read audit events continously?
by Jean-Jacques Pitrolle
Hi list,
I'm looking for an example to receive auditd event *continously* and
print them to the standard output.
I found simple example which use *auparse* library here:
https://security-plus-data-science.blogspot.com/2017/04/writing-basic-aup...
I add a the following lines to loop 'forever'
8<---
[..]
while (1) {
auparse_first_record(au);
[..]
sleep(1);
}
auparse_destroy(au);
return 0;
}
-->8
The problem with this example is the output only shows the events which
are available *before* binary startup not the event arrived *after*.
8<---
./dummy-auditd &
~ # Record type: DAEMON_START -
type,op,ver,format,kernel,auid,pid,uid,ses,res
Record type: CONFIG_CHANGE - type,op,audit_backlog_limit,old,auid,ses,res
[..]
Record type: PROCTITLE - type,proctitle
Record type: 0 - (null)
Record type: 0 - (null)
..
-->8
I want to have the event print *continously* i.e the new events *shall*
appears on the standard output.
Can you point me some examples in the git repository or an url that
describes how to do it please?
I surely miss something in the documentation so let me know if it is the
case.
Thanks.
Regards.
2 months, 3 weeks
libaudit: fill structure audit_rule_data to use audit_add_rule_data
by Jean-Jacques Pitrolle
Hello list,
This is my first message and i hope i will provide the expected
information to get help (:
I'm looking in libaudit if there is a function to transform a line in
audit.rules's format to a *struct audit_rule_data* to feed
*audit_add_rule_data* to insert a new rule.
From tag *v3.0.9* (i need to stick to this version for the moment), i
see occurences of *audit_add_rule_data* in *autrace.c* and *auditctl.c*
but it seems that adding a rule is specific to those binaries.
Do i understand it correctly?
Do i need to specifically write a basic rule parser to call
*audit_add_rule_data* with a new rule when i use libaudit?
Or does libaudit provides a general way to tranform an auditd rule (i.e
in format of audit.rules file) to a struct audit_rule_data?
Thanks for help.
Regards.
2 months, 4 weeks