Re: [PATCH bpf-next] bpf: emit audit messages upon successful prog load and unload
by Richard Guy Briggs
On 2018-10-07 18:19, Jesper Dangaard Brouer wrote:
> On Sat, 6 Oct 2018 00:05:22 +0200
> Jiri Olsa <jolsa(a)redhat.com> wrote:
>
> > On Fri, Oct 05, 2018 at 11:44:35AM -0700, Alexei Starovoitov wrote:
> > > On Fri, Oct 05, 2018 at 08:14:09AM +0200, Jiri Olsa wrote:
> > > > On Thu, Oct 04, 2018 at 03:10:15PM -0700, Alexei Starovoitov wrote:
> > > > > On Thu, Oct 04, 2018 at 10:22:31PM +0200, Jesper Dangaard Brouer wrote:
> > > > > > On Thu, 4 Oct 2018 21:41:17 +0200 Daniel Borkmann <daniel(a)iogearbox.net> wrote:
> > > > > >
> > > > > > > On 10/04/2018 08:39 PM, Jesper Dangaard Brouer wrote:
> > > > > > > > On Thu, 4 Oct 2018 10:11:43 -0700 Alexei Starovoitov <alexei.starovoitov(a)gmail.com> wrote:
> > > > > > > >> On Thu, Oct 04, 2018 at 03:50:38PM +0200, Daniel Borkmann wrote:
> > > > > > [...]
> > > > > > > >>
> > > > > > > >> If the purpose of the patch is to give user space visibility into
> > > > > > > >> bpf prog load/unload as a notification, then I completely agree that
> > > > > > > >> some notification mechanism is necessary.
> > > > > > >
> > > > > > > Yeah, I did only regard it as only that, nothing more. Some means
> > > > > > > of timeline and notification that can be kept in a record in user
> > > > > > > space and later retrieved e.g. for introspection on what has been
> > > > > > > loaded.
> > > > > > >
> > > > > > > >> I've started working on such mechanism via perf ring buffer which is
> > > > > > > >> the fastest mechanism we have in the kernel so far.
> > > > > > > >> See long discussion here: https://patchwork.ozlabs.org/patch/971970/
> > > >
> [...]
> > > > > > >
> > > > > > > That one is definitely needed in any case to resolve the kallsyms
> > > > > > > limitations, and it does have overlap in that in either case we
> > > > > > > want to look at past BPF programs that have been unloaded in the
> > > > > > > meantime, so I don't have a strong preference either way, and the
> > > > > > > former is needed in any case. Though thought was that audit might
> > > > > > > be an option for those not running profiling daemons 24/7, but
> > > > > > > presumably bpftool could be extended to record these events as
> > > > > > > well if we don't want to reuse audit infra.
> > > > > >
> > > > > > Yes, exactly, I don't want to run a profiling daemon 24/7 to record
> > > > > > these events. I do acknowledge that this perf event is relevant,
> > > > > > especially for catching the kernel symbols (I need that myself), but it
> > > > > > does not cover my use-case.
> > > > > >
> > > > > > My use-case is to 24/7 collect and keep records in userspace, and have a
> > > > > > timeline of these notifications, for later retrieval. The idea is that
> > > > > > our support engineers can look at these records when troubleshooting
> > > > > > the system. And the plan is also to collect these records as part of
> > > > > > our sosreport tool, which is part of the support case.
> > > > >
> > > > > I don't think you're implying that prog load/unload should be spamming dmesg
> > > > > and auditd not even running...
> > > >
> > > > I think the problem Jesper implied is that in order to collect
> > > > those logs you'll need perf tool running all the time.. which
> > > > it's not equipped for yet
> > >
> > > I'm not proposing to run 'perf' binary all the time.
> > > Setting up perf ring buffer just for these new bpf prog load/unload events
> > > and epolling it is simple enough to do from any application including auditd.
> > > selftests/bpf/ do it for bpf output events.
> >
> > ok, did not think about the possibility to teach auditd talk to perf,
> > time to get that tool evsel/evlist/rb library ready ;-)
>
> Interesting, I also didn't consider teaching auditd to gets its 'bpf'
> events from a separate perf ring-buffer, that might work. I do wonder
> how the audit people will take this suggestion.
Including the linux-audit list to get userspace audit folks in the
loop...
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
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
6 years, 2 months
audispd stopping on distribute-network = yes
by Lenny Bruzenak
Situation:
Have 3 VMs all running RHEL7.6 (3.10.0-933.el7.x86_64) with audit
components 2.8.4, including audisp-plugins. Using the audisp-remote plugin,
Machine A -> B
Machine B -> C
Problem 1:
If I enable "distribute_network = yes" on Machine B, audispd (and
children) stops.
No anom_abend, no message in syslog, no audit event I can identify as a
clue.
Problem 2:
If I disable the distribute_network, the audispd and audisp-remote work
fine.
If I reboot Machine B, Machine A now doesn't auto-reconnect. I thought
we had addressed these reconnect issues a ways back?
Thanks in advance for any advice,
LCB
--
Lenny Bruzenak
MagitekLTD
6 years, 2 months
auditd starting later in boot sequence, w/o ipV6
by Lenny Bruzenak
In case anyone has as much trouble as I do following instructions, here
is my /etc/systemd/system/auditd.service file excerpt, which enables the
auditd to start a bit later, especially after disabling ipV6 in the
kernel command options. Just showing the changed part. I first copied
the entire file from /usr/lib/systemd/system/auditd.service.
HTH,
LCB
#cat /etc/systemd/system/auditd.service
[Unit]
Description=Security Auditing Service
DefaultDependencies=no
## If auditd.conf has tcp_listen_port enabled, copy this file to
## /etc/systemd/system/auditd.service and add network-online.target
## to the next line so it waits for the network to start before launching.
After=network-online.target local-fs.target systemd-tmpfiles-setup.service
#Conflicts=shutdown.target
#Before=sysinit.target shutdown.target
Before=shutdown.target
Conflicts=shutdown.target
RefuseManualStop=yes
ConditionKernelCommandLine=!audit=0
Documentation=man:auditd(8)
https://github.com/linux-audit/audit-documentation
...
--
Lenny Bruzenak
MagitekLTD
6 years, 2 months
4.9 kernel panic in netlink unicast because audit replace passing audit sock as NULL
by Kassey Li
hi, Paul:
we got one kernel panic on 4.9 kernel
[16237.397896] [2018:10:09 23:06:55]audit: audit_pid=20802 reset
[16238.098916] [2018:10:09 23:06:57]Unable to handle kernel NULL pointer dereference at virtual address 00000280
audit_sock is set to NULL in kauditd_send_skb, but later we are access it again in audit_replace caused this panic.
is there patch for such SW issue on 4.9 kernel ?
static int audit_replace(pid_t pid)
{
struct sk_buff *skb = audit_make_reply(0, 0, AUDIT_REPLACE, 0, 0,
&pid, sizeof(pid));
if (!skb)
return -ENOMEM;
return netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
}
Br
kassey
6 years, 2 months
[PATCH] audit: Rename audit mark variable to amark
by Jan Kara
Variable of audit_tree_mark type was called 'mark' which is confusing as
we usually call fsnotify_mark variables this way. Rename it to 'amark'
to make it explicit this a actually a different thing.
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
kernel/audit_tree.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Hello Paul,
here is the patch to rename mark to amark as Richard suggested.
Honza
diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
index 9c53f7c37bdf..232b8b18cb5b 100644
--- a/kernel/audit_tree.c
+++ b/kernel/audit_tree.c
@@ -175,14 +175,14 @@ static void audit_tree_destroy_watch(struct fsnotify_mark *mark)
static struct fsnotify_mark *alloc_mark(void)
{
- struct audit_tree_mark *mark;
+ struct audit_tree_mark *amark;
- mark = kmem_cache_zalloc(audit_tree_mark_cachep, GFP_KERNEL);
- if (!mark)
+ amark = kmem_cache_zalloc(audit_tree_mark_cachep, GFP_KERNEL);
+ if (!amark)
return NULL;
- fsnotify_init_mark(&mark->mark, audit_tree_group);
- mark->mark.mask = FS_IN_IGNORED;
- return &mark->mark;
+ fsnotify_init_mark(&amark->mark, audit_tree_group);
+ amark->mark.mask = FS_IN_IGNORED;
+ return &amark->mark;
}
static struct audit_chunk *alloc_chunk(int count)
--
2.16.4
6 years, 2 months
Minimizing CPU Utilization of audisp Plugin
by Osama Elnaggar
Hi,
I'm currently working on a Python audisp plugin. My main routine looks
like this:
if __name__ == '__main__':
try:
...
aup = auparse.AuParser(auparse.AUSOURCE_FEED)
aup.add_callback(process_event, None)
while True:
for _ in fileinput.input():
aup.feed(_)
except:
...
While profiling my plugin, I noticed that 95% + of the CPU time used by my
plugin is used in fileinput.input(), waiting/reading from input
Is there any way to lower this or preferred way to poll/read?
Thanks
--
Osama Elnaggar
6 years, 2 months
audit log's server
by Levin Stanislav
Hello.
I try to use auditd as a server to gather logs from remote clients.
1) My conditions:
/rpm -q audit//
//audit-2.8.4/
/uname -r//
//4.9.124/
/ipv6 is disable/
2) Problem's symptom:
after every reboot of server machine i have
/from journalctl:/
/auditd[765]: Cannot create tcp listener socket
systemd[1]: auditd.service: Control process exited, code=exited status=1
auditd[764]: Cannot daemonize (Success)
systemd[1]: auditd.service: Failed with result 'exit-code'.
auditd[764]: The audit daemon is exiting.
systemd[1]: Failed to start Security Auditing Service./
//ss -lntp -o ' sport = 60 '//
////State Recv-Q Send-Q Local
Address:Port Peer Address:Port//
Later, on system boot, the service can be started manually without error.
3) Workarounds:
a) systemd
The header of auditd.service tells:
## If auditd.conf has tcp_listen_port enabled, copy this file to
## /etc/systemd/system/auditd.service and add network-online.target
## to the next line so it waits for the network to start before launching.
But this leads to circular dependencies in systemd, because auditd says:
"Before=sysinit.target", and network-online.target has not direct
"After=sysinit.target".
Systemd just skips auditd from boot in this case.
Of course, i can remove auditd's dep on sysinit.target, this breaks a loop.
b) ipv4 and ipv6
I've added some debug messages into auditd to see what happens.
Actually ipv6 module is disabled, but in this moment 'getaddrinfo'
within 'auditd_tcp_listen_init' returns both structures - AF_INET and
AF_INET6.
While auditd attempts to create AF_INET6 socket (skipping AF_INET) there
is an error message: "/Cannot create tcp listener socket/", errno
/EAFNOSUPPORT./
No chances to start./
/
After system boot there is AF_INET only.
I have attached the patch if one needs.
Could somebody suggest a proper solution to my problem?
Thank you in advance!
6 years, 2 months
ANOM_ROOT_TRANS
by Maupertuis Philippe
Hi,
According to the Redhat 7 security guide ANOM_ROOT_TRANS is triggered when a user becomes root.
It seems that using sudo doesn't trigger this event.
I would like to know how this event is triggered.
There are also several ANOM_ types that I can't see generated.
Is there a document describing from where these event would come.
Philippe
!!!*************************************************************************************
"Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
6 years, 2 months
