[PATCH v7 0/3] fanotify: Allow user space to pass back additional audit info
by Richard Guy Briggs
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
changelog:
v1:
- first version by Steve Grubb <sgrubb(a)redhat.com>
Link: https://lore.kernel.org/r/2042449.irdbgypaU6@x2
v2:
- enhancements suggested by Jan Kara <jack(a)suse.cz>
- 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.rgb@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.rgb@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.rgb@redhat.com
v5:
- fixed warnings in p2/4 and p3/4 found by <lkp(a)intel.com>
- 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.rgb@redhat.com
v6:
- simplify __audit_fanotify() from audit_log_format/audit_log_n_hex to audit_log/%X
- add comment to clarify {subj,obj}_trust values
- remove fd processing from process_access_response_info()
- return info_len immediately from process_access_response() on FAN_NOFD after process_access_response_info()
Link: https://lore.kernel.org/all/cover.1673989212.git.rgb@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.rgb@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
1 year, 10 months
- 4
- 13
[PATCH] audit: update the mailing list in MAINTAINERS
by Paul Moore
We've moved the upstream Linux Kernel audit subsystem discussions to
a new mailing list, this patch updates the MAINTAINERS info with the
new list address.
Marking this for stable inclusion to help speed uptake of the new
list across all of the supported kernel releases. This is a doc only
patch so the risk should be close to nil.
Cc: stable(a)vger.kernel.org
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7f86d02cb427..b686c3af313f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3511,7 +3511,7 @@ F: drivers/net/ieee802154/atusb.h
AUDIT SUBSYSTEM
M: Paul Moore <paul(a)paul-moore.com>
M: Eric Paris <eparis(a)redhat.com>
-L: linux-audit(a)redhat.com (moderated for non-subscribers)
+L: audit(a)vger.kernel.org
S: Supported
W: https://github.com/linux-audit
T: git git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
--
2.39.1
1 year, 10 months
- 1
- 1
Upstream kernel development and the linux-audit mailing list
by Paul Moore
Hello all,
Those of you who have been following the linux-audit mailing list
closely over the past several years have likely seen some issues
relating to upstream Linux Kernel development and the mailing list:
disagreements on the focus of the list (upstream vs upstream+distro),
and a moderated vs open posting policy.
In general the disagreements around the focus of the list, while
annoying at times, tended not to be significant issues.
Unfortunately, the issue of list moderation has been a problem with
other subsystem maintainers and developers dropping the audit list
from their discussions due to the moderation settings. While I had
hoped that we might change the list to an open list, just like most of
the upstream kernel mailing lists, Steve has mentioned that he does
not want to make the change due to concerns over SPAM.
With that in mind, I'm going to suggest moving the development of
audit in the upstream Linux Kernel to a new mailing list hosted on
vger.kernel.org. Many of you who participate, or at least monitor,
kernel development are no doubt already subscribed to at least one
mailing list hosted on vger as it is one of the most common (*the*
most common?) list host for Linux Kernel related development.
I don't want to make any statements with respect to Steve's audit
userspace, that is up to him, but I don't have any problem if he wants
to move upstream discussion of his audit userspace tools to the same
vger-based list.
I'll hold off on list creation for a couple of days in case anyone has
a well reasoned argument against moving upstream kernel development to
a new list. However, I want to underscore that any argument to keep
upstream discussions on a moderated list will need to be strong enough
to counter potentially excluding other subsystems from the discussion.
--
paul-moore.com
1 year, 10 months
- 1
- 2
Re: Re: audit library license
by 布施 博明
Hello,
Thank you for the comment.
I also find following commit.
- https://github.com/linux-audit/audit-userspace/commit/e63a8b1628170151016...
BTW, I found another license question.
The libauparse.so are created following source codes.
In 'auparse/Makefile.am'
AM_CPPFLAGS = -I. -I${top_srcdir} -I${top_srcdir}/src -I${top_srcdir}/lib -I${top_srcdir}/common
:
libauparse_la_SOURCES = lru.c interpret.c nvlist.c ellist.c \
auparse.c auditd-config.c message.c data_buf.c \
auparse-defs.h auparse-idata.h data_buf.h \
nvlist.h auparse.h ellist.h \
internal.h lru.h rnode.h interpret.h \
private.h expression.c expression.h tty_named_keys.h \
normalize.c normalize-llist.c normalize-llist.h \
normalize-internal.h normalize_obj_kind_map.h \
normalize_record_map.h normalize_syscall_map.h
We can find following line in internal.h
#include "auditd-config.h"
I can find src/auditd-config.h file which is GPLv2.
The "src/auditd-config.h" should be also LGPLv2.1
Regardss,
> ----- Original Message -----
>
> From: "Steve Grubb" <sgrubb(a)redhat.com>
> To: "linux-audit(a)redhat.com" <linux-audit(a)redhat.com>
> Cc: "hiroaki.fuse(a)ymail.ne.jp" <hiroaki.fuse(a)ymail.ne.jp>
> Date: 2023/02/01 水 00:53
> Subject: Re: audit library license
>
>
> Hello,
>
> On Monday, January 30, 2023 7:55:20 PM EST hiroaki.fuse(a)ymail.ne.jp wrote:
> > Dear All members,
> >
> > We can find following lines in audit/README file
> >
> > LICENSE
> > =======
> > The audit daemon is released as GPL'd code. The audit daemon's libraries
> > libaudit.* and libauparse.* are released under LGPL so that it may be
> > linked with 3rd party software.
> >
> > I found that latest audit library linked libaucommon.so.
> >
> > ./lib/Makefile.in:AM_CPPFLAGS = -I. -I${top_srcdir} -I${top_srcdir}/auparse
> > -I${top_srcdir}/common ./lib/Makefile.in:libaudit_la_LIBADD =
> > $(CAPNG_LDADD) ${top_builddir}/common/libaucommon.la
> > ./lib/Makefile.in:libaudit_la_DEPENDENCIES = $(libaudit_la_SOURCES)
> > ../config.h ${top_builddir}/common/libaucommon.la
> >
> > ./auparse/Makefile.am:AM_CPPFLAGS = -I. -I${top_srcdir} -I${top_srcdir}/src
> > -I${top_srcdir}/lib -I${top_srcdir}/common
> > ./auparse/Makefile.am:libauparse_la_LIBADD =
> > ${top_builddir}/lib/libaudit.la ${top_builddir}/common/libaucommon.la
> > ./auparse/Makefile.am:libauparse_la_DEPENDENCIES =
> > $(libauparse_la_SOURCES) ${top_builddir}/config.h
> > ${top_builddir}/common/libaucommon.la
> >
> > Libaucommo.so is created by following files
> >
> > ./common/Makefile.am:libaucommon_la_SOURCES = audit-fgets.c strsplit.c
> >
> > And the license of audit/common/audit-fgets.c is GPLv2
> >
> > This mean the license of latest audit libraries are also GPLv2.
> >
> > Is my understanding correct?
>
> The intention stated in the README file is correct. The code in question is
> only used by 3 plugins which are GPL and those functions are hidden from
> external users of libaudit. The code can be relicenced to make it LGPL so
> everything matches the intentions.
>
> -Steve
>
>
> --
> Linux-audit mailing list
> Linux-audit(a)redhat.com
> https://listman.redhat.com/mailman/listinfo/linux-audit
>
>
1 year, 10 months
- 3
- 2