On Thu, Jan 23, 2020 at 3:15 PM Richard Guy Briggs <rgb(a)redhat.com> wrote:
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.
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.
--
paul moore
www.paul-moore.com