4:40 p.m.
Is there any way to make pam_tty_audit log not only what the user types but
also what the server sends back? Due to regulatory requirements We are
currently having to use proprietary, kludgy, unreliable bastion host
"solutions" to get full session logging. It seems like pam_tty_audit, being in
the tty layer, would have access to everything going through the tty both send
and receive but it looks like only commands typed are logged. Am I missing
something?
Thanks!
--
Tracy Reed
7:59 a.m.
On Friday, June 07, 2013 06:48:18 PM Miloslav Trmač wrote:
----- Original Message -----
> Is there any way to make pam_tty_audit log not only what the user types
> but
> also what the server sends back?
No, this is currently not possible.
Impossible as in 1) what is already shipped can't do this, or 2) no amount of
code being added to the kernel can do this, or 3) for upstream political
reasons?
-Steve
10:48 a.m.
----- Original Message -----
On Friday, June 07, 2013 06:48:18 PM Miloslav Trmač wrote:
> ----- Original Message -----
>
> > Is there any way to make pam_tty_audit log not only what the user types
> > but
> > also what the server sends back?
>
> No, this is currently not possible.
Impossible as in 1) what is already shipped can't do this, or 2) no amount of
code being added to the kernel can do this, or 3) for upstream political
reasons?
Primarily 1), also
4) auditing output is a little more difficult because it's much more common to have a
_lot_ of output (e.g. (find -name '*.c')), so TTY auditing should probably be able
to throttle the TTY throughput. (In principle the same problem is with input as well -
with a PTY I can cause massive amount of data to be audited - but it doesn't occur
accidentally.)
Mirek
10:55 a.m.
On Monday, June 10, 2013 11:48:15 AM Miloslav Trmač wrote:
> > > Is there any way to make pam_tty_audit log not only
what the user
> > > types but also what the server sends back?
> >
> > No, this is currently not possible.
>
> Impossible as in 1) what is already shipped can't do this, or 2) no amount
> of code being added to the kernel can do this, or 3) for upstream
> political reasons?
Primarily 1), also
4) auditing output is a little more difficult because it's much more common
to have a _lot_ of output (e.g. (find -name '*.c')), so TTY auditing should
probably be able to throttle the TTY throughput. (In principle the same
problem is with input as well - with a PTY I can cause massive amount of
data to be audited - but it doesn't occur accidentally.)
Probably would need to escape/drop all the control characters, too, so report
display terminal doesn't get hijacked. :-) But yes, I could see someone
DoS'ing the machine easily now that you mention it.
-Steve
4212
days inactive
4215
days old
linux-audit@lists.linux-audit.osci.io
4 comments
3 participants
participants (3)
-
Miloslav Trmač -
Steve Grubb -
Tracy Reed