Re: [RFC] TTY auditing
Steve Grubb napsal(a):
> Summary
> -------
> A per-process "audit TTY input" attribute is added.
I wonder if this would be better hanging off the audit context? That's where
we put file names and other aux records.
The audit context is per-thread. Does it
make sense to have different
TTY audit settings for different threads within a process?
> Optionally, user-space applications can send advisory audit
events
> describing the "meaning" of the TTY input.
Its nice to have that capability, but I think in practice, it will mean
changing a lot of apps. So, I have this feeling that we shouldn't do it. We
can leave it there in case anyone wants to do that.
It is optional, input
characters are still logged if advisory events are
not created; it can be added to applications as the need arises. On the
other hand, I think it really is necessary for shells - system
administrators tend to use the command-line completion, editing and
history expansion extensively, and it may be very hard to reconstruct
the original command line from the TTY log alone.
> Auditing processes, not TTYs
> ----------------------------
> A potential problem with is approach is unwanted auditing of TTY input
> to system daemons run (or restarted) by an administrator;
This should be OK. There had better not be tty interaction to a daemon. It
should detach from ttys and open stdin to /dev/null. If it does that, does
the auditing end?
No, the "audit TTY input" flag is still set, even
though it doesn't
affect anything. But if the deamon detaches from TTys and _then_ opens
any TTY, the hack triggers.
> if the administrator restarts an *getty daemon, all inputs to the
daemon
> would be audited. As a special hack, opening a TTY in a process that has no
> TTY currently open automatically disables the "audit TTY input" flag.
> Closing the current TTY and opening another one does not really make any
> sense in a regular application, but daemons which close all file
> descriptors on startup would be handled by the hack. If the hack
> doesn't handle a specific daemon automatically, the daemon could either
> be modified to disable auditing, or its startup scripts could explicitly
> close TTYs to activate the hack.
We do not want a loophole for daemon's to change auditing.
We implicitly trust
the daemons not to stop auditing completely, anyway.
Changing the flag (without using the hack) requires CAP_AUDIT_CONTROL,
so the ability to disable auditing can be restricted.
> Is it enough to allow an administrative process to read/modify
its
> own "audit TTY input" attribute, or is it necessary to access the
attribute
> of other processes?
It should be set by login processes and then be immutable. IOW, it can't be
turned off.
In that case, after (/sbin/service sshd restart) executed from an
audited session, all SSH future sessions would be audited, including
sessions of unprivileged users.
Thanks for the comments.
Mirek