Re: Tough question for oracle DBAs/Solaris Admins. Log shipping.

On Fri, 1 Sep 2006 23:33:06 +0200 Stefaan A Eeckels <hoendech_at_ecc.lu> wrote:
> On 1 Sep 2006 12:28:12 -0700
> "Karen Hill" <karen_hill22_at_yahoo.com> wrote:
>
>> Immutable files are files where not even root
>> can change/delete/move a file set as immutable.
>
> But root can unset the immutable flag. Thus it only serves as
> protection against accidental deletions or modifications. This is
> slightly useful. Roles are better for that purpose.
>
>> For the Oracle DBAs, how can you guarentee an audit trail without
>> immutable files?
>
> You cannot guarantee it with immutable files.
>
> Immutability is _not_ a security feature. It does _not_ solve the
> problem that root can change any file.

In *BSD, it can. You can disable unsetting the immutable flag.

> If you cannot trust your root user, you've got major problems. Trust
> is a difficult concept for PHBs, but there is no magic solution.

For some environments, root indeed has to be untrusted. e.g. kerberized NFS can be setup in such a way that root on the local box does not get you access to data you shouldn't have access to. (lots of ifs and buts here, of course).

Anyway, if shipping a log file off the machine is enough to meet audit requirements, then immutability shouldn't come into the picture. You might have an immutable configuration that ships the logs (which would protect against root changing this config), but root can change routing to intercept the logs and alter them. Even if the system is so locked down that this can't be done, root probably has physical access to the machine and can insert his interceptor device. Even if that's not the case, some network admin has access and can do this. So ultimately you have to have trusted employees. Audit controls are about protecting yourself from UNTRUSTED employees, not eliminating trust from the system.

No auditor will balk at not having immutable files as long as only trusted employees are in the position to undetectably alter data.

-frank Received on Fri Sep 01 2006 - 17:07:44 CDT