Date:	Thu, 7 Jun 2007 10:33:04 -0700 (PDT)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Steve Grubb <sgrubb@...hat.com>, 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


--- Steve Grubb <sgrubb@...hat.com> wrote:


> 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

My knee jerk response is "good luck with that". I hope you're not
planning a GUI, because tracing the mouse movements, clicks, and
window placement in order to identify what action the admin is taking
is going to be a without-a-net trick.

> If we do not get commands typed at a prompt, we have to audit by execve. 

I would suggest that you'll have to do that as well so that you can tell
the difference between typed actions like these:

# cat > /dev/null
badprogram --badthing --everyone
^D
#

# badprogram --badthing --everyone

where the same typed line is a Bad Thing in one case and completely
irrelevent in the other.

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

Yes. Your Linux system performs millions (yea, billions) of security
relevent actions in the time it takes you (well, me) to spell check an
lkml posting. Audit systems spew lots of data because there's lots of
data that is required to track who did what to whom.

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

OK. They're not willing to pay the price for the result they are asking for.

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

If the requirement is that all human initiated administrative actions
be audited your only option is to seriously restrict the actions that
the human can perform by hand. This is usually accomplished by providing
an administration user interface facility as the admin shell. This shell
only invokes a tightly controlled set of commands, and audits their
parameters.

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

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

As an adjunct to system level audit it might be helpful, but
it cannot stand on its own.


Casey Schaufler
casey@...aufler-ca.com
-
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