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

From: <jKILLSPAM.schipper_at_math.uu.nl>
Date: 09 Sep 2006 09:38:32 GMT
Message-ID: <45028b98$0$31782$dbd49001@news.wanadoo.nl>

In comp.unix.bsd.openbsd.misc Casper H.S. Dik <Casper.Dik_at_sun.com> wrote:
> "tedu" <tu_at_zeitbombe.org> writes:

>>immutability is an attribute of the inode.  mounting does not affect
>>the inodes of the covered filesystem.  it would be silly to think the
>>attribute applied to a filename.  file permissions do not apply to the
>>name, why would you expect what amounts to a read-only flag to be
>>different?

>
> immutability also prevents a file from being removed or renamed;
> it is more than an attribute of the filename; it's an attribute
> of the filename AT THAT LOCATION.
>
> If you want to prevent unlinking then it stands to reason you also
> prevent mounting on top off.

I actually believe that this is a result of immutability of the underlying directory; therefore, one could say that mounting over a directory which is marked as immutable should not be allowed.

However, this is largely irrelevant. Exploiting this issue presumes the attacker has already gained root priviliges; and while root on OpenBSD does not have access to kernel memory, he does have access to all processes - and I believe that systrace, which is in the base system, would suffice for redirecting all requests to /usr/bin/* to /myhacks/evilstuff. Which could optionally peek at argv[0] to see what was intended and execute that after doing whatever one wants to do.

Again, kernel-level compromise should not be possible; but root *is* able to arbitrarily manipulate syscalls, which isn't that far off. About the best the kernel can guarantee in this case is that the system will come up `clean' when rebooted, and OpenBSD's securelevels do achieve that (or not, but at least the issue with mount is not the cause of their failing).

About the only time your proposal would be useful is if someone misconfigured sudo to allow arbitrary mounts - but then again, if your security is sufficiently high that the addition of immutable files outweighs the gain from other, less intrusive, changes, it is *very* unlikely that such a misconfiguration exists.

                Joachim Received on Sat Sep 09 2006 - 04:38:32 CDT