On Fri, 1 Sep 2006 23:33:06 +0200 Stefaan A Eeckels <hoendech@ecc.lu> wrote:
> On 1 Sep 2006 12:28:12 -0700
> "Karen Hill" <karen_hill22@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