[RFC] TTY auditing
Miloslav Trmac
mitr at redhat.com
Sat Jun 2 13:25:49 UTC 2007
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
More information about the Linux-audit
mailing list