Re: [RFC] TTY auditing
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