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

[Bruno Raoult <braoult@example.com>]

On Mon, Sep 28, 2009 at 17:57, Curt Sampson <cjs@example.com> 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.

Maybe. But I will not say anything about this... I got their requirements.
I will surely not ask for more strong rules...

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

The auditing being automatic, the developers will no need to forget anything...

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

So I guess you configure apache with root account... Which is worse
than anything...
"root" was a very bad idea in Unix systems... Old VMS systems had
better management
systems...

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

Good point. I totally agree... But Audit will not. They agree we are
not dealing with malicious
users. But they want to be sure the log files are untouched... Their
logic is not mine :-)

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

Maybe not: A "grep" will allow to find commands, right?

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

Yes, except that we are speaking about production system. For instance:
"I cannot send an order to SGX, opening is in 3 minutes...". In that
case we need to
check log files, call brokers, and make a fast change...
We really make the changes directly on production systems for this reason.

Bruno.

-- 
2 + 2 = 5, for very large values of 2.