lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 7 Jun 2007 12:31:43 -0400
From:	Steve Grubb <sgrubb@...hat.com>
To:	casey@...aufler-ca.com
Cc:	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Miloslav Trmac <mitr@...hat.com>, dwmw2@...radead.org,
	linux-kernel@...r.kernel.org, Alan Cox <alan@...hat.com>,
	Alexander Viro <aviro@...hat.com>
Subject: Re: [PATCH] Audit: Add TTY input auditing

On Thursday 07 June 2007 11:42, Casey Schaufler wrote:
> > tools like rootsh, but that is too easy to detect and defeat. And then it
> > does not put its data into the audit system where its correlated with
> > other system events.
>
> The evaluation teams that I have worked with (OrangeBook and CC)
> as well as their technical advisory groups have always been clear
> that keyboard logging is not an appropriate mechanism for security
> audit logging. There is insufficient correlation between what is
> typed and security relevent actions for keyboard (or mouse event)
> logging to meet the audit requirements.

Ok, this is a sample set of requirements we are trying to meet:

Implement automated audit trails for all system components to reconstruct the 
following events:
  All actions taken by any individual with root or administrative privileges

If we do not get commands typed at a prompt, we have to audit by execve. 
Auditing execve for uid = 0 produces millions of events since that includes 
daemons. If we get clever and restrict auditing to events for root uid and 
auid >= 500, we still wind up with millions of events because of shell 
scripts. 

People in control of some of these security targets said to me that auditing 
by execve cannot be the solution, because the audit trail becomes too big, 
unwieldy, full of irrelavent events, and not easily analysed. So, that 
approach does not work for people either.

Casey, so what approach would you take to meet the requirement?

> You have to log what happened.

Which can be done by auditing for execution of specific apps or watching 
access to certain files. So, I don't see tty auditing as something that 
replaces other auditing, it allows us to form a better picture of what 
happened to the system.

> Logging what was requested is insufficient and logging what was
> typed, which may or may not have resulted in an actual request is
> not helpful to meeting security audit requirements.

I would disagree. Its helpful to complete the picture of what's happening on 
the system.

-Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ