SEO

Stefaan A Eeckels 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.

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.

> > 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.

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.

> 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.

Karen Hill wrote:
> Stefaan A Eeckels 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.
>
> 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.

Do you mean they'd have to reboot to do it at all, or do you mean that
they'd have to reboot to do it in a supported manner? I strongly
suspect it's the latter. After all, at some level, it's all bits and
bytes (both on disk and in RAM), so if you can execute privileged
instructions on the processor, you can do whatever you want, period.

- Logan

In comp.unix.bsd.openbsd.misc Logan Shaw <lshaw-usenet@austin.rr.com> wrote:
> Karen Hill wrote:
>> Stefaan A Eeckels 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.
>>
>> 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.
>
> Do you mean they'd have to reboot to do it at all, or do you mean that
> they'd have to reboot to do it in a supported manner? I strongly
> suspect it's the latter. After all, at some level, it's all bits and
> bytes (both on disk and in RAM), so if you can execute privileged
> instructions on the processor, you can do whatever you want, period.

I am not currently aware of any way to change the runlevel from a
running OpenBSD system - by design, root cannot execute kernel-level
('priviliged' in your message, I believe) code.

One of the ways of doing this is denying access to kernel memory - see
mem(4), securelevel(7) on a OpenBSD system.

However, see my other message...

Joachim

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

jKILLSPAM.schipper@math.uu.nl wrote:
> In comp.unix.bsd.openbsd.misc Logan Shaw <lshaw-usenet@austin.rr.com> wrote:
>> Karen Hill wrote:
>>> Stefaan A Eeckels wrote:
>>>> On 1 Sep 2006 12:28:12 -0700
>>>> "Karen Hill" <karen_hill22@yahoo.com> wrote:

>>>> But root can unset the immutable flag.

>>> 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.

>> Do you mean they'd have to reboot to do it at all, or do you mean that
>> they'd have to reboot to do it in a supported manner? I strongly
>> suspect it's the latter. After all, at some level, it's all bits and
>> bytes (both on disk and in RAM), so if you can execute privileged
>> instructions on the processor, you can do whatever you want, period.

> I am not currently aware of any way to change the runlevel from a
> running OpenBSD system - by design, root cannot execute kernel-level
> ('priviliged' in your message, I believe) code.
>
> One of the ways of doing this is denying access to kernel memory - see
> mem(4), securelevel(7) on a OpenBSD system.

Well, that's a very different kind of root than what I'm familiar with,
but I suppose you could do it that way.

I guess this means that if you try to go this route, you have to worry
about loadable kernel modules. Solaris, of course, has them and depends
heavily on them. Perhaps one solution to this is to make the entire
tree of kernel modules (including all the directories) immutable as well.

- Logan

In comp.unix.bsd.openbsd.misc Logan Shaw <lshaw-usenet@austin.rr.com> wrote:
> jKILLSPAM.schipper@math.uu.nl wrote:
>> In comp.unix.bsd.openbsd.misc Logan Shaw <lshaw-usenet@austin.rr.com> wrote:
>>> Karen Hill wrote:
>>>> Stefaan A Eeckels wrote:
>>>>> On 1 Sep 2006 12:28:12 -0700
>>>>> "Karen Hill" <karen_hill22@yahoo.com> wrote:
>
>>>>> But root can unset the immutable flag.
>
>>>> 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.
>
>>> Do you mean they'd have to reboot to do it at all, or do you mean that
>>> they'd have to reboot to do it in a supported manner? I strongly
>>> suspect it's the latter. After all, at some level, it's all bits and
>>> bytes (both on disk and in RAM), so if you can execute privileged
>>> instructions on the processor, you can do whatever you want, period.
>
>> I am not currently aware of any way to change the runlevel from a
>> running OpenBSD system - by design, root cannot execute kernel-level
>> ('priviliged' in your message, I believe) code.
>>
>> One of the ways of doing this is denying access to kernel memory - see
>> mem(4), securelevel(7) on a OpenBSD system.
>
> Well, that's a very different kind of root than what I'm familiar with,
> but I suppose you could do it that way.
>
> I guess this means that if you try to go this route, you have to worry
> about loadable kernel modules. Solaris, of course, has them and depends
> heavily on them. Perhaps one solution to this is to make the entire
> tree of kernel modules (including all the directories) immutable as well.

OpenBSD does not allow loading of kernel modules once the securelevel
has been raised above 0; this typically happens as part of the boot
procedure. This aspect of securelevels is actually quite useful.

Also, OpenBSD's kernel is not very modular - there is a module
framework, but almost everything is compiled straight into the kernel.
Only in rare circumstances do you actually load any modules - for
instance, the OpenAFS port needs a kernel module. But that's the only
one I ever needed.

This design actually makes a lot of sense; surely, modules can save a
small amount of memory, but it is usually not very significant. And it's
a rare occurence that even a Linux system loads a module once the system
is 'really up'.

Finally, note the aforementioned problem with immutable files - you can
always mount another file system over the parent directory (in OpenBSD,
obviously).

This is not to say that root can't do truly nasty stuff; trojaning all
binaries and rm'ing the rest is pretty bad, for instance, and messing
with the bootloader is always good fun... (although securelevel 2 would
prevent that, but very few systems run at securelevel 2, as quite a few
things - notably, parts of the firewall subsystem like ftp-proxy - have
difficulty working. Plus, it isn't the default.)

Joachim

jKILLSPAM.schipper@math.uu.nl writes:

>OpenBSD does not allow loading of kernel modules once the securelevel
>has been raised above 0; this typically happens as part of the boot
>procedure. This aspect of securelevels is actually quite useful.

It is somewhat problematic for a kernel as Solaris where everything
is rather dynamic; not being able to load the device driver for the
PCI device you've just hotplugged is a bit awkward.

Having the user immutability (which you can switch off) is useful in
itself because it prevents accidental deletion and modification.

In order to support hard immutability you can think of mechanisms like
file signatures; as long as you load only pre-configured trusted modules,
that is fine.

>This design actually makes a lot of sense; surely, modules can save a
>small amount of memory, but it is usually not very significant. And it's
>a rare occurence that even a Linux system loads a module once the system
>is 'really up'.

Not so on Solaris.

>Finally, note the aforementioned problem with immutable files - you can
>always mount another file system over the parent directory (in OpenBSD,
>obviously).

Sounds like a bug.

>This is not to say that root can't do truly nasty stuff; trojaning all
>binaries and rm'ing the rest is pretty bad, for instance, and messing
>with the bootloader is always good fun... (although securelevel 2 would
>prevent that, but very few systems run at securelevel 2, as quite a few
>things - notably, parts of the firewall subsystem like ftp-proxy - have
>difficulty working. Plus, it isn't the default.)

A lot of stuff becomes a lot harder when you can't change anything; for one,
administration without endangering uptime.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

jKILLSPAM.schipper@math.uu.nl wrote:

> This design actually makes a lot of sense; surely, modules can save a
> small amount of memory, but it is usually not very significant. And it's
> a rare occurence that even a Linux system loads a module once the system
> is 'really up'.

This would be a disaster for Solaris, or for any other system which
needs to support dynamic reconfiguration. For instance devices (and
processors, memory etc) may appear and disappear at, really, any point
while the system is up, and it needs to be able to load and
(preferably) unload modules when this happens.

--tim

In comp.unix.bsd.openbsd.misc Casper H.S. Dik <Casper.Dik@sun.com> wrote:
> jKILLSPAM.schipper@math.uu.nl writes:
>
>>OpenBSD does not allow loading of kernel modules once the securelevel
>>has been raised above 0; this typically happens as part of the boot
>>procedure. This aspect of securelevels is actually quite useful.
>
> It is somewhat problematic for a kernel as Solaris where everything
> is rather dynamic; not being able to load the device driver for the
> PCI device you've just hotplugged is a bit awkward.

Well, OpenBSD probably wouldn't handle the hotplugging, anyway.

> Having the user immutability (which you can switch off) is useful in
> itself because it prevents accidental deletion and modification.

OpenBSD's rm(1) does warn you when trying to delete a file that is
either not owned by you, not writable by you, or probably meets a list
of other criteria I can't think of offhand.

Such protections are not extended to root, though - root is presumed to
know what (s)he is doing.

> In order to support hard immutability you can think of mechanisms like
> file signatures; as long as you load only pre-configured trusted modules,
> that is fine.

Well, as long as the kernel can be trusted to verify these signatures
correctly, if I understand you correctly. This is not a given.

>>This design actually makes a lot of sense; surely, modules can save a
>>small amount of memory, but it is usually not very significant. And it's
>>a rare occurence that even a Linux system loads a module once the system
>>is 'really up'.
>
> Not so on Solaris.

Really? While I think the ability to *do* this hotplugging is really
neat, I would imagine that - outside of hotswapping disks - this would
be quite rare.

Just curious - do you need this feature often?

>>Finally, note the aforementioned problem with immutable files - you can
>>always mount another file system over the parent directory (in OpenBSD,
>>obviously).
>
> Sounds like a bug.

A lot of people agree with you; Theo, though, thinks securelevels are
broken anyways.

Most probably, both camps are right.

>>This is not to say that root can't do truly nasty stuff; trojaning all
>>binaries and rm'ing the rest is pretty bad, for instance, and messing
>>with the bootloader is always good fun... (although securelevel 2 would
>>prevent that, but very few systems run at securelevel 2, as quite a few
>>things - notably, parts of the firewall subsystem like ftp-proxy - have
>>difficulty working. Plus, it isn't the default.)
>
> A lot of stuff becomes a lot harder when you can't change anything; for one,
> administration without endangering uptime.

Indeed, which is another reason why securelevel 2 is not used often.

However, if OpenBSD is deployed as a redundant firewall, uptime becomes
much less important, and securelevel 2 might make sense. Still, I would
most likely not use it.

Joachim

In comp.unix.bsd.openbsd.misc Tim Bradshaw <tfb+google@tfeb.org> wrote:
> jKILLSPAM.schipper@math.uu.nl wrote:
>
>> This design actually makes a lot of sense; surely, modules can save a
>> small amount of memory, but it is usually not very significant. And it's
>> a rare occurence that even a Linux system loads a module once the system
>> is 'really up'.
>
> This would be a disaster for Solaris, or for any other system which
> needs to support dynamic reconfiguration. For instance devices (and
> processors, memory etc) may appear and disappear at, really, any point
> while the system is up, and it needs to be able to load and
> (preferably) unload modules when this happens.

I assume that some kind of warning must be given before one can remove
devices; still, this is 'wicked cool'.

Not enough to make me switch to Solaris, of course, but wicked cool.

There is, BTW, no particular requirement for dynamic loading; OpenBSD
just compiles every driver [1] into the kernel, so dynamic
reconfiguration can be done without loading any additional drivers.
However, I'm fairly certain most subsystems can't deal with devices
randomly appearing and disappearing - in particular, I'm fairly certain
the memory subsystem would get very, very confused.

Of course, you *can* plug in a USB device, and it will mostly Just Work
- but hotswapping CPUs is not possible.

Joachim

[1] Subject to certain constraints, mostly that the driver must be
stable, usable, and useful for more than ten persons or somesuch.