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

[Bruno Raoult <braoult@example.com>]

On Mon, Sep 28, 2009 at 18:58, Curt Sampson <cjs@example.com> wrote:
> On 2009-09-28 18:32 +0900 (Mon), Bruno Raoult wrote:
>
>> Maybe. But I will not say anything about this... I got their requirements.
>> I will surely not ask for more strong rules...
>
> Boy, I'm sure glad you don't work for me!

Hehehe: Sure you would not work for me too, if you prefer to help
audit instead of
business...

You misunderstand me for sure: We discussed this point also in my
team, and don't think
this request is good at all... But I have no reason to do more (than
requested) on this
subject, because this would just take us more time for *nothing*...
I just consider this as an "administrative" request.

>> > Those accounts [such as "apache"] 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...
>
> I certainly do not; I use separate role accounts for each application.

"role account". This is exactly what I am speaking about.
"sudo -u role-account" is exactly what I call using a "generic account".
Again, how do you practically manage apache (or equivalent) config files?
They are in CVS or so, apparently. But how do you make the *real*
change?

> As for the slightly scornful tone I imagine I perceive in your comment,
> keep in mind that it's you, not me, who is breaking one of the primary
> and most basic rules of security and auditing: users must never share
> authentication information.

Of course, we do not share any authentication information! this is why
we use application specific accounts (what you call "role account", what
I call "application account"). Not accessible with ssh, etc, etc...

> Keep in mind that, in finance, not keeping proper audit records can not
> only lose data and money, but can open up your company to legal and
> possibly even criminal liability.

Obviously. But don't mix-up trading and support...
Japan law wants a 10 years record of trading orders (new/amend/cancel)...
They don't need executions log (obviously).
They don't require to get a log of support functions actions (but will of course
ask for an explanation in case of something wrong happens).

>> Maybe not: A "grep" will allow to find commands, right?
>
> Perhaps. It depends on what else is in the output. In particular, screen
> control codes can mess things up. I just tried script on a session where
> I typed "ec^Hcho foo" and, no surprise, the word "echo" does not appear
> in the script file.

I was thinking about "greping" on prompt rather than commands, just to
get rid of
the commands output (this was my first issue with "script", if you remember).

> By the way, there are a lot of things like this that can trip you up.
> If you missed this quite obvious one, you're probably missing a lot of
> others, too.
>
>> > For configuration files in particular, I suggest keeping them in
>> > revision control.
>>
>> Yes, except that we are speaking about production system.
>
> Yes, I am suggesting keeping configuration files for production systems
> in revision control. I do it all the time.
>
>> 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.
>
> Right. That in no way precludes using revision control.

If time is an issue, yes it is: Check-in, check-out, then sudo to the production
account on 3-4 machines to get the new version is just loosing these 3
minutes...
Better change first on prod machines, and later make things updated on revision
system (what we do)...

br.

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