[RFC] TTY auditing

[Steve Grubb]

On Friday 01 June 2007 18:07:17 Miloslav Trmac wrote:
> Hello,
> the attached patches propose a way to audit administrative commands.

Thanks for working on this problem. This should close the last gap for NISPOM, 
PCI, and DCID 6/3. Its important to have this capability.

> 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.

> 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.

> Fundamental limitations
> -----------------------
> Only TTY input is logged, so an administrator may execute unknown code
> by downloading shell scripts over the network. 

This is fine. We just need whatever they type.

> 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?

> 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.


> Semantics of the logged data
> ----------------------------

<snip>

> As a special case, input read when the TTY is using ICANON without ECHO
> is _not_ audited, to avoid storing passwords in the audit log.

I think we should audit everything or this becomes the hole to issue commands 
that are not audited. The audit logs are high integrity and should be 
trusted.

> Attached code
> -------------
> - a kernel patch, against a current-ish Linux tree.
> - a patch against audit-1.5.3 to recognize the new netlink message types
> - a PAM module which allows enabling/disabling TTY auditing on login
> - a patch against readline-5.2 to generate advisory audit events on
>   returned strings.  The exact same patch can be used for the readline
>   copy included in bash-3.2.
>
> Unresolved questions:
> ---------------------
> The advisory audit events may be emitted by any process for which TTY
> input is audited, no additional privileges are necessary.  Is it
> necessary to separately limit the rate of the generated events, or is
> the current kernel rate limit sufficient?

In a way, I don't like unprivileged processes having the ability to create 
events programmaticly. It could be easily used to DoS the audit system. Maybe 
we shouldn't worry about advisory records.

> Reading and modifying the "audit TTY input" attribute using a the audit
> netlink socket works, but it feels unnatural.  Should it be done
> differently (e.g. /proc, prctl ())? 

No, I'd rather keep everything going through the same interface for many 
reasons. SE Linux policy being one of them.

> 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.

Briefly looking at the kernel patch, it should have "auid" logged in the 
events. I'll send separate feedback on the kernel patch, though.

In general, I think this is a much more thorough approach than the bash audit 
patch I worked up earlier this year and more likely to meet the real needs.

Thanks,
-Steve