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

From: <jKILLSPAM.schipper_at_math.uu.nl>
Date: 03 Sep 2006 11:43:14 GMT
Message-ID: <44fabfd2$0$5348$dbd4f001@news.wanadoo.nl>

In comp.unix.bsd.openbsd.misc Karen Hill <karen_hill22_at_yahoo.com> wrote:
> Stefaan A Eeckels 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.

>
> Not when they are at a networked run level according to the OpenBSD man
> page on the subject. They would have to reboot, or bring it down to
> single user mode to do that. Rebooting an OS running a production
> database would be extremely difficult to cover by an admin.

Note, though, that people *can* mount a filesystem over it. This possibility has always been present and should be clear when reading the manpage; however, it appears someone made a lot of noise, and NetBSD and, I believe, FreeBSD patched runlevel(7) to disallow mounts. See the Full-Disclosure archives, for instance, or http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4351. (Note that CVE is wrongly suggesting that newer OpenBSD versions are not 'vulnerable'.)

Theo decided against it, giving as a reason that runlevels are terribly broken anyway. ISTR that the Linux maintainer didn't want to bother with further tinkering and so let the issue slide.

>> > For the Oracle DBAs, how can you guarentee an audit trail without
>> > immutable files?
>>
>> You cannot guarantee it with immutable files.

>
> Are you sure? I'm read in the man pages that root cannot change or
> delete an immutable file in BSD without rebooting the server. And
> restarting a server is something that one could easily detect. I'm
> adding the openbsd group to see if they have anything to add of
> relevance to the immutable file discussion.

See the above.

> OpenBSD is a great system, unfortunately, scaling up to the processor
> level required to run a medium sized corporate database server is
> something only Solaris / AIX seem to be able to do.

I believe Linux is getting there, slowly - but yes, from what I've heard, Solaris would be my system of choice.

Still, some clustering solutions can work well even on less bulky machines.

>> Immutability is _not_ a security feature. It does _not_ solve the
>> problem that root can change any file. 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.
>> Learn to live with it.

>
> When an auditor has to sign off on it, "learn to live with it" is not a
> very good solution when dealing with Sarb-Ox.

Nonetheless, root still is god. There are some Linux patches that try to change this (RSBAC is bundled with GrSecurity, and comes to mind; idem for SELinux, and at least one alternative I forgot - I've not run Linux for quite a while now), but they tend to either not work, break POSIX compliance in a way that causes strange behaviour in quite a few cases, or both. Of course, a knowledgeable admin can make them work...

Running everything chroot()ed, with no priviliges, is a far better solution; add systrace(1) if you want to restrict the process further. (Note that systrace(1) incurs a performance hit; also, I believe a port to Linux is stabilizing.)

Finally, and this is inspired by the above discussion, Theo & friends strongly believe in 'actual security' instead of 'security features' or 'auditability'. Linux + RSBAC is very auditable, but OpenBSD is likely to be more secure, if only due to lack of kernel-level vulnerabilities. Thus, OpenBSD is not the best system if you want auditability.

                Joachim Received on Sun Sep 03 2006 - 06:43:14 CDT