Re: [RFC] TTY auditing

[Miloslav Trmac <mitr@redhat.com>]

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