Re: [PATCH] bpf: emit audit messages upon successful prog load and unload
by Paul Moore
On Wed, Nov 20, 2019 at 4:49 PM Alexei Starovoitov
<alexei.starovoitov(a)gmail.com> wrote:
> On Wed, Nov 20, 2019 at 1:46 PM Daniel Borkmann <daniel(a)iogearbox.net> wrote:
> > On 11/20/19 10:38 PM, Jiri Olsa wrote:
> > > From: Daniel Borkmann <daniel(a)iogearbox.net>
> > >
> > > Allow for audit messages to be emitted upon BPF program load and
> > > unload for having a timeline of events. The load itself is in
> > > syscall context, so additional info about the process initiating
> > > the BPF prog creation can be logged and later directly correlated
> > > to the unload event.
> > >
> > > The only info really needed from BPF side is the globally unique
> > > prog ID where then audit user space tooling can query / dump all
> > > info needed about the specific BPF program right upon load event
> > > and enrich the record, thus these changes needed here can be kept
> > > small and non-intrusive to the core.
> > >
> > > Raw example output:
> > >
> > > # auditctl -D
> > > # auditctl -a always,exit -F arch=x86_64 -S bpf
> > > # ausearch --start recent -m 1334
> > > [...]
> > > ----
> > > time->Wed Nov 20 12:45:51 2019
> > > type=PROCTITLE msg=audit(1574271951.590:8974): proctitle="./test_verifier"
> > > type=SYSCALL msg=audit(1574271951.590:8974): arch=c000003e syscall=321 success=yes exit=14 a0=5 a1=7ffe2d923e80 a2=78 a3=0 items=0 ppid=742 pid=949 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="test_verifier" exe="/root/bpf-next/tools/testing/selftests/bpf/test_verifier" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> > > type=UNKNOWN[1334] msg=audit(1574271951.590:8974): auid=0 uid=0 gid=0 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=949 comm="test_verifier" exe="/root/bpf-next/tools/testing/selftests/bpf/test_verifier" prog-id=3260 event=LOAD
> > > ----
> > > time->Wed Nov 20 12:45:51 2019
> > > type=UNKNOWN[1334] msg=audit(1574271951.590:8975): prog-id=3260 event=UNLOAD
> > > ----
> > > [...]
> > >
> > > Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
> > > Signed-off-by: Jiri Olsa <jolsa(a)kernel.org>
> >
> > LGTM, thanks for the rebase!
>
> Applied to bpf-next. Thanks!
[NOTE: added linux-audit to the To/CC line]
Wait a minute, why was the linux-audit list not CC'd on this? Why are
you merging a patch into -next that adds to the uapi definition *and*
creates a new audit record while we are at -rc8?
Aside from that I'm concerned that you are relying on audit userspace
changes that might not be okay; I see the PR below, but I don't see
any comment on it from Steve (it is his audit userspace). I also
don't see a corresponding test added to the audit-testsuite, which is
a common requirement for new audit functionality (link below). I'm
also fairly certain we don't want this new BPF record to look like how
you've coded it up in bpf_audit_prog(); duplicating the fields with
audit_log_task() is wrong, you've either already got them via an
associated record (which you get from passing non-NULL as the first
parameter to audit_log_start()), or you don't because there is no
associated syscall/task (which you get from passing NULL as the first
parameter). Please revert, un-merge, etc. this patch from bpf-next;
it should not go into Linus' tree as written.
Audit userspace PR:
* https://github.com/linux-audit/audit-userspace/pull/104
Audit test suite:
* https://github.com/linux-audit/audit-testsuite
Audit folks, here is a link to the thread in the archives:
* https://lore.kernel.org/bpf/20191120213816.8186-1-jolsa@kernel.org/T/#u
--
paul moore
www.paul-moore.com
4 years, 11 months
[PATCH AUTOSEL 4.9 04/13] audit_get_nd(): don't unlock parent too early
by Sasha Levin
From: Al Viro <viro(a)zeniv.linux.org.uk>
[ Upstream commit 69924b89687a2923e88cc42144aea27868913d0e ]
if the child has been negative and just went positive
under us, we want coherent d_is_positive() and ->d_inode.
Don't unlock the parent until we'd done that work...
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
kernel/audit_watch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index f036b6ada6efc..712469a3103ac 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -365,12 +365,12 @@ static int audit_get_nd(struct audit_watch *watch, struct path *parent)
struct dentry *d = kern_path_locked(watch->path, parent);
if (IS_ERR(d))
return PTR_ERR(d);
- inode_unlock(d_backing_inode(parent->dentry));
if (d_is_positive(d)) {
/* update watch filter fields */
watch->dev = d->d_sb->s_dev;
watch->ino = d_backing_inode(d)->i_ino;
}
+ inode_unlock(d_backing_inode(parent->dentry));
dput(d);
return 0;
}
--
2.20.1
4 years, 11 months
[PATCH AUTOSEL 4.14 06/21] audit_get_nd(): don't unlock parent too early
by Sasha Levin
From: Al Viro <viro(a)zeniv.linux.org.uk>
[ Upstream commit 69924b89687a2923e88cc42144aea27868913d0e ]
if the child has been negative and just went positive
under us, we want coherent d_is_positive() and ->d_inode.
Don't unlock the parent until we'd done that work...
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
kernel/audit_watch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 4a98f6e314a9b..35f1d706bd5b4 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -365,12 +365,12 @@ static int audit_get_nd(struct audit_watch *watch, struct path *parent)
struct dentry *d = kern_path_locked(watch->path, parent);
if (IS_ERR(d))
return PTR_ERR(d);
- inode_unlock(d_backing_inode(parent->dentry));
if (d_is_positive(d)) {
/* update watch filter fields */
watch->dev = d->d_sb->s_dev;
watch->ino = d_backing_inode(d)->i_ino;
}
+ inode_unlock(d_backing_inode(parent->dentry));
dput(d);
return 0;
}
--
2.20.1
4 years, 11 months
[PATCH AUTOSEL 4.19 06/25] audit_get_nd(): don't unlock parent too early
by Sasha Levin
From: Al Viro <viro(a)zeniv.linux.org.uk>
[ Upstream commit 69924b89687a2923e88cc42144aea27868913d0e ]
if the child has been negative and just went positive
under us, we want coherent d_is_positive() and ->d_inode.
Don't unlock the parent until we'd done that work...
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
kernel/audit_watch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 787c7afdf8294..4f7262eba73d8 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -366,12 +366,12 @@ static int audit_get_nd(struct audit_watch *watch, struct path *parent)
struct dentry *d = kern_path_locked(watch->path, parent);
if (IS_ERR(d))
return PTR_ERR(d);
- inode_unlock(d_backing_inode(parent->dentry));
if (d_is_positive(d)) {
/* update watch filter fields */
watch->dev = d->d_sb->s_dev;
watch->ino = d_backing_inode(d)->i_ino;
}
+ inode_unlock(d_backing_inode(parent->dentry));
dput(d);
return 0;
}
--
2.20.1
4 years, 11 months
Auditd SYSCALL argument decoding
by Tim Galyean
Hello,
As I understand it, long values recorded by auditd are stored as hex encoded strings. However, when I attempt to decode arguments such as a0 or a1 in SYSCALL events, they are decoded into special characters instead of ASCII. Are these values encoded differently than PROCTITLE events?
Below is an example log line:
type=SYSCALL msg=audit(1574182099.559:2002): arch=c000003e syscall=59 success=yes exit=0 a0=55df330a3c10 a1=55df330a3c78 a2=55df330a3c90 a3=0 items=3 ppid=29664 pid=29678 auid=1171 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=170 comm="apt-check" exe="/usr/bin/python3.5" key="rootcmd"
In this example, I am looking to decode a0, a1, and a2. Yes, it seems that ausearch can decode these values. However, I am looking to decode them via Splunk. What format are these strings encoded in and is there a way to decode these values in any other way other than by using ausearch?
4 years, 11 months
[PATCH v11 00/25] LSM: Module stacking for AppArmor
by Casey Schaufler
Sending the patches relevant to audit to the linux-audit list.
This patchset provides the changes required for
the AppArmor security module to stack safely with any other.
v11: Rebase to 5.4-rc6
Incorporate feedback from v10
- Disambiguate reading /proc/.../attr/display by restricting
all use of the interface to the current process.
- Fix a merge error in AppArmor's display attribute check
v10: Ask the security modules if the display can be changed.
v9: There is no version 9
v8: Incorporate feedback from v7
- Minor clean-up in display value management
- refactor "compound" context creation to use a common
append_ctx() function.
v7: Incorporate feedback from v6
- Make setting the display a privileged operation. The
availability of compound contexts reduces the need for
setting the display.
v6: Incorporate feedback from v5
- Add subj_<lsm>= and obj_<lsm>= fields to audit records
- Add /proc/.../attr/context to get the full context in
lsmname\0value\0... format as suggested by Simon McVittie
- Add SO_PEERCONTEXT for getsockopt() to get the full context
in the same format, also suggested by Simon McVittie.
- Add /sys/kernel/security/lsm_display_default to provide
the display default value.
v5: Incorporate feedback from v4
- Initialize the lsmcontext in security_secid_to_secctx()
- Clear the lsmcontext in all security_release_secctx() cases
- Don't use the "display" on strictly internal context
interfaces.
- The SELinux binder hooks check for cases where the context
"display" isn't compatible with SELinux.
v4: Incorporate feedback from v3
- Mark new lsm_<blob>_alloc functions static
- Replace the lsm and slot fields of the security_hook_list
with a pointer to a LSM allocated lsm_id structure. The
LSM identifies if it needs a slot explicitly. Use the
lsm_id rather than make security_add_hooks return the
slot value.
- Validate slot values used in security.c
- Reworked the "display" process attribute handling so that
it works right and doesn't use goofy list processing.
- fix display value check in dentry_init_security
- Replace audit_log of secids with '?' instead of deleting
the audit log
v3: Incorporate feedback from v2
- Make lsmblob parameter and variable names more
meaningful, changing "le" and "l" to "blob".
- Improve consistency of constant naming.
- Do more sanity checking during LSM initialization.
- Be a bit clearer about what is temporary scaffolding.
- Rather than clutter security_getpeersec_dgram with
otherwise unnecessary checks remove the apparmor
stub, which does nothing useful.
Patche 0001 moves management of the sock security blob from the individual
modules to the infrastructure.
Patches 0002-0012 replace system use of a "secid" with
a structure "lsmblob" containing information from the
security modules to be held and reused later. At this
point lsmblob contains an array of u32 secids, one "slot"
for each of the security modules compiled into the
kernel that used secids. A "slot" is allocated when
a security module requests one.
The infrastructure is changed to use the slot number
to pass the correct secid to or from the security module
hooks.
It is important that the lsmblob be a fixed size entity
that does not have to be allocated. Several of the places
where it is used would have performance and/or locking
issues with dynamic allocation.
Patch 0013 provides a mechanism for a process to
identify which security module's hooks should be used
when displaying or converting a security context string.
A new interface /proc/self/attr/display contains the name
of the security module to show. Reading from this file
will present the name of the module, while writing to
it will set the value. Only names of active security
modules are accepted. Internally, the name is translated
to the appropriate "slot" number for the module which
is then stored in the task security blob. Setting the
display requires that all modules using the /proc interfaces
allow the transition. The "display" of other processess
can be neither read nor written. All suggested cases
for reading the display of a different process have race
conditions.
Patch 0014 Starts the process of changing how a security
context is represented. Since it is possible for a
security context to have been generated by more than one
security module it is now necessary to note which module
created a security context so that the correct "release"
hook can be called. There are several places where the
module that created a security context cannot be inferred.
This is achieved by introducing a "lsmcontext" structure
which contains the context string, its length and the
"slot" number of the security module that created it.
The security_release_secctx() interface is changed,
replacing the (string,len) pointer pair with a lsmcontext
pointer.
Patches 0015-0017 convert the security interfaces from
(string,len) pointer pairs to a lsmcontext pointer.
The slot number identifying the creating module is
added by the infrastructure. Where the security context
is stored for extended periods the data type is changed.
The Netlabel code is converted to save lsmblob structures
instead of secids in Patches 0018-0019.
Patch 0020 adds checks to the binder hooks which verify
that if both ends of a transaction use the same "display".
Patches 0021-0022 add addition data to the audit records
to identify the LSM specific data for all active modules.
Patches 0023-0024 add new interfaces for getting the
compound security contexts.
Finally, with all interference on the AppArmor hooks
removed, Patch 0025 removes the exclusive bit from
AppArmor. An unnecessary stub hook was also removed.
The Ubuntu project is using an earlier version of
this patchset in their distribution to enable stacking
for containers.
Performance measurements to date have the change
within the "noise". The sockperf and dbench results
are on the order of 0.2% to 0.8% difference, with
better performance being as common as worse. The
benchmarks were run with AppArmor and Smack on Ubuntu.
https://github.com/cschaufler/lsm-stacking.git#stack-5.4-rc6-v11-apparmor
Signed-off-by: Casey Schaufler <casey(a)schaufler-ca.com>
---
arch/alpha/include/uapi/asm/socket.h | 1 +
arch/mips/include/uapi/asm/socket.h | 1 +
arch/parisc/include/uapi/asm/socket.h | 1 +
arch/sparc/include/uapi/asm/socket.h | 1 +
drivers/android/binder.c | 26 +-
fs/ceph/xattr.c | 6 +-
fs/nfs/nfs4proc.c | 22 +-
fs/nfsd/nfs4xdr.c | 20 +-
fs/proc/base.c | 2 +
include/linux/audit.h | 1 +
include/linux/cred.h | 3 +-
include/linux/lsm_hooks.h | 37 +-
include/linux/security.h | 175 ++++++++--
include/net/af_unix.h | 2 +-
include/net/netlabel.h | 8 +-
include/net/scm.h | 15 +-
include/uapi/asm-generic/socket.h | 1 +
kernel/audit.c | 72 +++-
kernel/audit.h | 9 +-
kernel/audit_fsnotify.c | 1 +
kernel/auditfilter.c | 10 +-
kernel/auditsc.c | 127 ++++---
kernel/cred.c | 12 +-
net/core/sock.c | 7 +-
net/ipv4/cipso_ipv4.c | 6 +-
net/ipv4/ip_sockglue.c | 12 +-
net/netfilter/nf_conntrack_netlink.c | 20 +-
net/netfilter/nf_conntrack_standalone.c | 11 +-
net/netfilter/nfnetlink_queue.c | 26 +-
net/netfilter/nft_meta.c | 13 +-
net/netfilter/xt_SECMARK.c | 5 +-
net/netlabel/netlabel_kapi.c | 6 +-
net/netlabel/netlabel_unlabeled.c | 97 +++---
net/netlabel/netlabel_unlabeled.h | 2 +-
net/netlabel/netlabel_user.c | 13 +-
net/netlabel/netlabel_user.h | 6 +-
net/unix/af_unix.c | 6 +-
net/xfrm/xfrm_policy.c | 2 +
net/xfrm/xfrm_state.c | 2 +
security/apparmor/include/apparmor.h | 3 +-
security/apparmor/include/net.h | 6 +-
security/apparmor/lsm.c | 117 +++----
security/commoncap.c | 7 +-
security/integrity/ima/ima.h | 15 +-
security/integrity/ima/ima_api.c | 11 +-
security/integrity/ima/ima_appraise.c | 6 +-
security/integrity/ima/ima_main.c | 49 +--
security/integrity/ima/ima_policy.c | 19 +-
security/integrity/integrity_audit.c | 1 +
security/loadpin/loadpin.c | 8 +-
security/safesetid/lsm.c | 8 +-
security/security.c | 593 +++++++++++++++++++++++++++++---
security/selinux/hooks.c | 109 +++---
security/selinux/include/classmap.h | 2 +-
security/selinux/include/objsec.h | 5 +
security/selinux/include/security.h | 1 +
security/selinux/netlabel.c | 25 +-
security/selinux/ss/services.c | 4 +-
security/smack/smack.h | 6 +
security/smack/smack_lsm.c | 124 ++++---
security/smack/smack_netfilter.c | 8 +-
security/smack/smackfs.c | 10 +-
security/tomoyo/tomoyo.c | 8 +-
security/yama/yama_lsm.c | 7 +-
64 files changed, 1376 insertions(+), 563 deletions(-)
4 years, 11 months
Re: Not seeing access denied audit messages in restricted subdirectories
by Steve Grubb
Hello,
On Sat, 9 Nov 2019 21:58:33 -0700
"John T Olson" <jtolson(a)us.ibm.com> wrote:
> If I were to officially request this type of functionality from the
> kernel team (throw an event even without a valid path), how would I
> do that?
Just file an issue here:
https://github.com/linux-audit/audit-kernel/issues
-Steve
> From: Steve Grubb <sgrubb(a)redhat.com>
> To: Lenny Bruzenak <lenny(a)magitekltd.com>
> Cc: linux-audit(a)redhat.com
> Date: 11/09/2019 03:09 AM
> Subject: [EXTERNAL] Re: Not seeing access denied audit
> messages in restricted subdirectories
> Sent by: linux-audit-bounces(a)redhat.com
>
>
>
> On Sat, 9 Nov 2019 20:18:45 +1100
> Lenny Bruzenak <lenny(a)magitekltd.com> wrote:
> > On 11/9/19 8:39 AM, Steve Grubb wrote:
> >
> > > On Fri, 8 Nov 2019 13:39:58 -0700
> > > "John T Olson" <jtolson(a)us.ibm.com> wrote:
> > >
> > >> Greetings,
> > >>
> > >> I have the following 2 audit rules set up:
> > >>
> > >> -a always,exit -F arch=b64 -S all -F exit=-EACCES -F
> > >> dir=/gpfs/fs1 -a always,exit -F arch=b64 -S all -F exit=-EPERM
> > >> -F dir=/gpfs/fs1
> > >>
> > >> I have a directory structure like the following:
> > >>
> > >> (13:15:26) zippleback-vm1:~ # ls -la /gpfs/fs1/test/
> > >> total 257
> > >> drwx------. 3 root root 4096 Nov 7 12:46 .
> > >> drwxr-xr-x. 15 root root 262144 Nov 7 12:50 ..
> > >> drwx------. 2 root root 4096 Nov 7 12:46 test2
> > >>
> > >> Essentially, directory "/gpfs/fs1/test/" is owned by root and has
> > >> permissions 700. The subdirectory underneath it (with
> > >> path /gpfs/fs1/test/test2) is also owned by root and has
> > >> permissions 700.
> > >>
> > >> When I have a non-root user attempt to list the contents of
> > >> directory "/gpfs/fs1/test/" I receive an audit message for the
> > >> denied access. However, when the non-root user attempts to list
> > >> the contents of the subdirectory (/gpfs/fs1/test/test2), there is
> > >> no audit message generated. Does anyone know why this is and how
> > >> I get audit messages in both cases?
> > > Yes, the reason is because the path did not resolve so audit never
> > > saw it. This has been this way for quite some time. In the past,
> > > it was said because the path never resolved, a PATH record with
> > > all attributes could not be generated. I have mentioned to kernel
> > > maintainers, that the path is available as a syscall argument.
> > > While a full PATH record cannot be generated with file attributes,
> > > an abbreviated one could be generated. So, far...no one has saw
> > > this as a big enough problem to fix. Personally, I think it should
> > > be fixed.
> > At first blush, I completely agree. However, I'm wondering if the
> > first attempt completely failed, how would the second one even have
> > the knowledge of the unattainable path?
>
> Because it was an argument to the syscall. For example, if its the
> open syscall, then arg0 points to the path. You cannot create a
> completed PATH record because you have no device, inode, or mode. But
> you do have the attempted path.
>
>
> > In the real world if the first one failed (in this example
> > /gpfs/fs1/test), because although the parent directory would list
> > the test directory, it is not reachable. But the listing of that one
> > would not happen at all (/gpfs/fs1/test/test2), because the non-root
> > user had no access to the listing dir (/gpfs/fs1/test). The caller
> > would have had to gain knowledge of its existence through other
> > means.
> >
> > I wonder if even acknowledging its existence via a "denied access"
> > event would be slightly counter-productive? The abbreviated PATH
> > would be nice, and since it is there, sure, why not? Then, if all
> > calls either to non-existent or say access-denied paths looked the
> > same, then that would be fine I think. I would not be as happy if
> > one could sniff out inaccessible directories (as opposed to
> > non-existent) from audited events though.
>
> Only sysadmins have access to the audit trail. And I think you can
> sniff out inaccessible directories with a little shell or python
> scripting as a non-admin user. Of course doing so should cause some
> metric to spike.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit(a)redhat.com
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailm...
>
>
>
>
>
4 years, 11 months
Not seeing access denied audit messages in restricted subdirectories
by John T Olson
Greetings,
I have the following 2 audit rules set up:
-a always,exit -F arch=b64 -S all -F exit=-EACCES -F dir=/gpfs/fs1
-a always,exit -F arch=b64 -S all -F exit=-EPERM -F dir=/gpfs/fs1
I have a directory structure like the following:
(13:15:26) zippleback-vm1:~ # ls -la /gpfs/fs1/test/
total 257
drwx------. 3 root root 4096 Nov 7 12:46 .
drwxr-xr-x. 15 root root 262144 Nov 7 12:50 ..
drwx------. 2 root root 4096 Nov 7 12:46 test2
Essentially, directory "/gpfs/fs1/test/" is owned by root and has
permissions 700. The subdirectory underneath it (with
path /gpfs/fs1/test/test2) is also owned by root and has permissions 700.
When I have a non-root user attempt to list the contents of directory
"/gpfs/fs1/test/" I receive an audit message for the denied access.
However, when the non-root user attempts to list the contents of the
subdirectory (/gpfs/fs1/test/test2), there is no audit message generated.
Does anyone know why this is and how I get audit messages in both cases?
Thanks,
John
John T. Olson, Ph.D., MI.C., K.EY.
Master Inventor, Software Defined Storage
957/9032-1 Tucson, AZ, 85744
(520) 799-5185, tie 321-5185 (FAX: 520-799-4237)
Email: jtolson(a)us.ibm.com
Follow me on twitter: @John_T_Olson
"Do or do not. There is no try." - Yoda
Olson's Razor:
Any situation that we, as humans, can encounter in life
can be modeled by either an episode of The Simpsons
or Seinfeld.
4 years, 11 months
RHEL 8 audit rules
by MAUPERTUIS, PHILIPPE
Hi,
The rules proposed in /usr/share/doc/audit/rules/ contain 32 bits stuff.
For example :
## 10.2.5.b All elevation of privileges is logged
-a always,exit -F arch=b64 -S setuid -F a0=0 -F exe=/usr/bin/su -F key=10.2.5.b-elevated-privs-session
-a always,exit -F arch=b32 -S setuid -F a0=0 -F exe=/usr/bin/su -F key=10.2.5.b-elevated-privs-session
Is it still necessary for RHEL 8 ?
Would the 21-no32bit.rules be enough ?
Can we run any 32 bits binary on rhel 8 ?
Regards
Philippe
equensWorldline is a registered trade mark and trading name owned by the Worldline Group through its holding company.
This e-mail and the documents attached are confidential and intended solely for the addressee. If you receive this e-mail in error, you are not authorized to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. EquensWorldline and the Worldline Group therefore can accept no liability for any errors or their content. Although equensWorldline and the Worldline Group endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with equensWorldline and the Worldline Group by email
4 years, 12 months
Re: ntp audit spew.
by Paul Moore
On Mon, Sep 23, 2019 at 11:50 AM Dave Jones <davej(a)codemonkey.org.uk> wrote:
>
> I have some hosts that are constantly spewing audit messages like so:
>
> [46897.591182] audit: type=1333 audit(1569250288.663:220): op=offset old=2543677901372 new=2980866217213
> [46897.591184] audit: type=1333 audit(1569250288.663:221): op=freq old=-2443166611284 new=-2436281764244
> [48850.604005] audit: type=1333 audit(1569252241.675:222): op=offset old=1850302393317 new=3190241577926
> [48850.604008] audit: type=1333 audit(1569252241.675:223): op=freq old=-2436281764244 new=-2413071187316
> [49926.567270] audit: type=1333 audit(1569253317.638:224): op=offset old=2453141035832 new=2372389610455
> [49926.567273] audit: type=1333 audit(1569253317.638:225): op=freq old=-2413071187316 new=-2403561671476
>
> This gets emitted every time ntp makes an adjustment, which is apparently very frequent on some hosts.
>
>
> Audit isn't even enabled on these machines.
>
> # auditctl -l
> No rules
[NOTE: added linux-audit to the CC line]
There is an audit mailing list, please CC it when you have audit
concerns/questions/etc.
What happens when you run 'auditctl -a never,task'? That *should*
silence those messages as the audit_ntp_log() function has the
requisite audit_dummy_context() check. FWIW, this is the distro
default for many (most? all?) distros; for example, check
/etc/audit/audit.rules on a stock Fedora system. A more selective
configuration could simply exclude the TIME_ADJNTPVAL record (type
1333) from the records that the kernel emits.
We could also add a audit_enabled check at the top of
audit_ntp_log()/__audit_ntp_log(), but I imagine some of that depends
on the various security requirements (they can be bizzare and I can't
say I'm up to date on all those - Steve Grubb should be able to
comment on that).
--
paul moore
www.paul-moore.com
4 years, 12 months
