Re: [tlug] comand-line recording...

[Curt Sampson <cjs@example.com>]

On 2009-09-28 17:05 +0900 (Mon), Bruno Raoult wrote:

> The situation: Developers and support people. They all have access to
> production machines. Audit does not like it.

> So what I proposed the audit was: "we cannot avoid to have developers
> accessing our production environment. But we will have a log of what
> they do on this environment. Thay said it was an acceptable solution.

That seems like a reasonable stop-gap measure to fill in for the moment,
until you can implement something better.

What I'm suspecting here is that you've fallen into the situation
where the audit people said "the developers must not be able to change
the audit logfile," but really meant that they wanted developers to
be unable to subvert the auditing. If you explain to them that there
are many other ways of subverting the auditing, and that developers
modifying the log files is far less likely to happen accidently than
many of these other subversions (such as forgetting to turn on the
auditing!), they may drop that requirement as fairly pointless, freeing
up your time and energy to concentrate on fixing the overall problem
rather than just that one aspect of it.

> > I don't use generic accounts myself, for a lot of very good reasons....

> I am sure you do use generic accounts. root is one.
> If you have an "apache" server, what is its uid? Yours? Surely not.

Those accounts exist; no person ever logs into them, or is able to log
into them. (They have neither password nor ssh access.) Any particular
person always logs into a machine using an account dedicated to him
only. Anything done as those "role" accounts is done through using sudo
to run a command as that user, which is logged.

> I want to know that Fred changed a config file, on Wednesday 3:00, and
> I want to know that Joe did something at 3:05 on the same file. And
> They should not be able to change this history files (syslog is fine,
> then)...

I think that the requirement "they should not be able to change the
history files" is badly specified, and what you really want is,
"they should not be able to subvert the logging." That's probably an
impractical requirement, so you need to look instead at the most common
ways the logging could be subverted, and try and deal with those.
Especially if you are not dealing with malicious users, you want to
concentrate on that common human errors, of which modifying log files is
not a typical one.

Keep in mind, also, that an audit trail is useful only to the extent
that it can also be processed, as well as generated. Using script to
track who's edited a file, especially if it's edited using a visual
editor, is going to be very difficult to audit, since the script file is
going to be quite difficult to read.

For configuration files in particular, I suggest keeping them in
revision control. That provides an excellent way to track who changed
a file, when, and what the changes were. There are a lot of ways of
implementing this particular idea, of course, and the details of what
will work well for you will vary widely depending on all of the other
details of your particular situation.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com