lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 18 Feb 2020 16:23:43 -0500 From: Richard Guy Briggs <rgb@...hat.com> To: Paul Moore <paul@...l-moore.com> Cc: Eric Paris <eparis@...isplace.org>, nhorman@...hat.com, Linux-Audit Mailing List <linux-audit@...hat.com>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH ghak28 V4] audit: log audit netlink multicast bind and unbind events On 2020-01-23 16:45, Paul Moore wrote: > On Thu, Jan 23, 2020 at 3:15 PM Richard Guy Briggs <rgb@...hat.com> wrote: > > On 2020-01-23 14:07, Paul Moore wrote: > > > On Thu, Jan 23, 2020 at 1:52 PM Richard Guy Briggs <rgb@...hat.com> wrote: > > > > On 2020-01-23 11:57, Paul Moore wrote: > > > > > On Thu, Jan 23, 2020 at 11:14 AM Richard Guy Briggs <rgb@...hat.com> wrote: > > > > > > On 2020-01-23 09:32, Paul Moore wrote: > > > > > > > On Wed, Jan 22, 2020 at 6:07 PM Richard Guy Briggs <rgb@...hat.com> wrote: > > > > > > > > On 2020-01-22 17:40, Paul Moore wrote: > > > > > > > > > On Fri, Jan 17, 2020 at 3:21 PM Richard Guy Briggs <rgb@...hat.com> wrote: > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > diff --git a/kernel/audit.c b/kernel/audit.c > > > > > > > > > > index 17b0d523afb3..478259f3fa53 100644 > > > > > > > > > > --- a/kernel/audit.c > > > > > > > > > > +++ b/kernel/audit.c > > > > > > > > > > @@ -1520,20 +1520,60 @@ static void audit_receive(struct sk_buff *skb) > > > > > > > > > > audit_ctl_unlock(); > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > +/* Log information about who is connecting to the audit multicast socket */ > > > > > > > > > > +static void audit_log_multicast_bind(int group, const char *op, int err) > > > > > > > > > > +{ > > > > > > > > > > + const struct cred *cred; > > > > > > > > > > + struct tty_struct *tty; > > > > > > > > > > + char comm[sizeof(current->comm)]; > > > > > > > > > > + struct audit_buffer *ab; > > > > > > > > > > + > > > > > > > > > > + if (!audit_enabled) > > > > > > > > > > + return; > > > > > > > > > > + > > > > > > > > > > + ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_EVENT_LISTENER); > > > > > > > > > > + if (!ab) > > > > > > > > > > + return; > > > > > > > > > > + > > > > > > > > > > + cred = current_cred(); > > > > > > > > > > + tty = audit_get_tty(); > > > > > > > > > > + audit_log_format(ab, "pid=%u uid=%u auid=%u tty=%s ses=%u", > > > > > > > > > > + task_pid_nr(current), > > > > > > > > > > + from_kuid(&init_user_ns, cred->uid), > > > > > > > > > > + from_kuid(&init_user_ns, audit_get_loginuid(current)), > > > > > > > > > > + tty ? tty_name(tty) : "(none)", > > > > > > > > > > + audit_get_sessionid(current)); > > > > > > > > > > > > > > > > > > Don't we already get all of that information as part of the syscall record? > > > > > > > > > > > > > > > > Yes. However, the syscall record isn't always present. One example is > > > > > > > > systemd, shown above. > > > > > > > > > > > > > > Assuming that the system supports syscall auditing, the absence of a > > > > > > > syscall record is a configuration choice made by the admin. If the > > > > > > > system doesn't support syscall auditing the obvious "fix" is to do the > > > > > > > work to enable syscall auditing on that platform ... but now we're > > > > > > > starting to get off topic. > > > > > > > > > > > > Well, the system did spit out a syscall record with the example above, > > > > > > so it has support for syscall auditing. > > > > > > > > > > > > I'm testing on f30 with an upstream kernel, the standard 30-stig ruleset and > > > > > > with kernel command line audit=1. What else is needed to support a syscall > > > > > > record on systemd before any audit rules have been put in place? We may still > > > > > > have a bug here that affects early process auditing. What am I missing? > > > > > > > > > > > > If we can get that sorted out, we don't need subject attributes in this record. > > > > > > > > > > It looks like some debugging is in order. There must be some sort of > > > > > action initiated by userspace which is causing the multicast > > > > > "op=connect", right? Find out what that is and why it isn't > > > > > generating a syscall record (maybe it's not a syscall? I don't know > > > > > what systemd is doing here). > > > > > > > > One clue is that subj=kernel and auid, ttye and ses are unset, despite > > > > the rest checking out: > > > > pid=1 uid=root auid=unset tty=(none) ses=unset subj=kernel comm=systemd exe=/usr/lib/systemd/systemd > > > > > > Does Fedora use systemd in its initramfs (I'm guessing the answer is > > > "yes")? If so, I wonder if that is the source of this record. > > > > Asking around, I got: "yes, dracut uses systemd these days" > > > > So, yes, that is the source of this record. > > > > So if there is no syscall associated with that record, it appears we > > need those subject attributes. > > Well, I'm fairly certain that the record in question was the result of > a syscall made by systemd, the question is why was it not recorded? > That is something that needs to be answered. The answer is in the ghak120 patch just posted. See: https://github.com/linux-audit/audit-kernel/issues/120 As for the drop, well it appears that more than one termination records are asynchronous (due to rcu locking) and will not have a directly attributable syscall. This applies to this issue and to ghak25. > paul moore - RGB -- Richard Guy Briggs <rgb@...hat.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
Powered by blists - more mailing lists