On 2019-04-09 19:25, Eric W. Biederman wrote:
Minor nit about the description of this patch (as I presume it will
need
to respun).
You are talking about audit signal information. You are not talking
about struct siginfo (aka siginfo_t). The structure siginfo_t is part
of posix and userspace ABI and is part of the stack frame for a
delivered signal.
The summary had me thinking you were messing with when siginfo is
collected and delivered to userspace.
Got it. I'll switch it to at least sig_info if not something even a bit
more descriptive and less confusing.
Richard Guy Briggs <rgb(a)redhat.com> writes:
> On 2019-04-09 17:37, Steve Grubb wrote:
>> On Tue, 9 Apr 2019 10:02:59 -0400
>> Richard Guy Briggs <rgb(a)redhat.com> wrote:
>>
>> > On 2019-04-09 08:01, Steve Grubb wrote:
>> > > On Mon, 8 Apr 2019 23:52:29 -0400 Richard Guy Briggs
>> > > <rgb(a)redhat.com> wrote:
>> > > > When a process signals the audit daemon (shutdown, rotate,
resume,
>> > > > reconfig) but syscall auditing is not enabled, we still want to
>> > > > know the identity of the process sending the signal to the audit
>> > > > daemon.
>> > >
>> > > Why? If syscall auditing is disabled, then there is no requirement
>> > > to provide anything. What is the real problem that you are seeing?
>> >
>> > Shutdown messages with -1 in them rather than the real values.
>>
>> OK. We can fix that by patching auditd to see if auditing is enabled
>> before requesting signal info. If auditing is disabled, the proper
>> action is for the kernel to ignore any audit userspace messages except
>> the configuration commands.
>
> If auditing is disabled in the kernel, none of this is trackable. It is
> for those as yet unsupported arches that can run audit enabled but
> without auditsyscall support.
>
> Here's a current sample with CONFIG_AUDIT and ~CONFIG_AUDITSYSCALL
> configured, note "auid=" and "pid=":
>
> killall -HUP auditd
> type=DAEMON_CONFIG msg=audit(2019-04-09 11:37:04.508:3266) op=reconfigure
state=changed auid=unset pid=-1 subj=? res=success
>
> killall -TERM auditd
> type=DAEMON_END msg=audit(2019-04-09 11:51:50.441:5709) : op=terminate auid=unset
pid=-1 subj=? res=success
>
> and the same with the patch applied:
>
> killall -HUP auditd
> type=DAEMON_CONFIG msg=audit(2019-04-09 11:42:40.851:8924) op=reconfigure
state=changed auid=root pid=652 subj=? res=success
>
> killall -TERM auditd
> type=DAEMON_END msg=audit(2019-04-09 11:51:50.441:5709) : op=terminate auid=root
pid=652 subj=? res=success
>
> The USR1 "rotate" and USR2 "resume" log messages need to be
fixed in
> userspace.
Hmm. You mention -1 as beeing a problem. You don't say if auid is a
concern.
Ok, -1 can be a real value if it isn't actually set, but in this case,
there is information available that isn't being used.
It looks like all you care about is the sending processes pid. That
information is saved in the sending processes siginfo. As such you may
be able to remove some of the magic from the code by looking at the
siginfo of the signal.
We need the sending process' pid, auid and ses, as well as its security
context label and the reason I noticed all this is that soon we'll also
want the audit container identifier as well.
So some of this information is available in siginfo, but I don't know if
all of it is.
Why it appears the kernel is logging when userspace receives a signal
is
beyond me so I don't know using siginfo makes sense. I just figure I
will toss it out there in case it shakes some ideas loose.
That is worth checking to see if it is all available.
Thanks, Eric.
Eric
- 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