On 2020-01-23 14:07, Paul Moore wrote:
On Thu, Jan 23, 2020 at 1:52 PM Richard Guy Briggs
<rgb(a)redhat.com> wrote:
> On 2020-01-23 11:57, Paul Moore wrote:
> > On Thu, Jan 23, 2020 at 11:14 AM Richard Guy Briggs <rgb(a)redhat.com>
wrote:
> > > On 2020-01-23 09:32, Paul Moore wrote:
> > > > On Wed, Jan 22, 2020 at 6:07 PM Richard Guy Briggs
<rgb(a)redhat.com> wrote:
> > > > > On 2020-01-22 17:40, Paul Moore wrote:
> > > > > > On Fri, Jan 17, 2020 at 3:21 PM Richard Guy Briggs
<rgb(a)redhat.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.
Next question, why do the other records generated from the test not
automatically trigger a syscall record when audit=1 on the kernel
command line?
paul moore
- 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