Actually no in this case the "academic" distinction is entirely correct. The
file has NOT been replaced, modified, spindled or otherwise mutilated. It
still exists, it has the same inode, it stil exists within the original
directory structure/etc. Simply put a new directory structure and pointer to
a new inode or network file system has been laid overtop of it's parent
directory.
What is the suggestion for a "solution" BTW? Everytime I mount a file system
it's supposed to traverse the entire file structure "below" the mount point
and check for any immutable flags? Do we add some sort of table, everytime a
file is set immutable an entry is added so we canjust check the table
quickly? No thanks.
Personally I think OpenBSD's response is entirely acceptable and I will
continue to use it (in fact I'm moving more servers to it).
P.S. you may want to read up on "accepting risk". Not all risk must be
mitigated/etc.
P.P.S The quote" Here is a perfectly reasonable response that could have
been used in place of what was offered.
"Due to inherent weaknesses with the securelevel system, securelevels will
not be included in any future release of OpenBSD.""
Is a straw man, OpenBSD is unlikely to remove a feature that doesn't cause
harm and more importantly and removing them would require touching a lot of
code and potentially introducing a new set of security flaws.
This is one of the weakest articles I've ever read, it simply comes across
as whinging (a step down from whining).
-Kurt
-------------------------------------------------------------------------
This List Sponsored by: Watchfire
Watchfire's AppScan is the industry's first and leading web application
security testing suite, and the only solution to provide comprehensive
remediation tasks at every level of the application. See for yourself.
Download AppScan 6.0 today.
https://www.watchfire.com/securearea/appscansix.aspx?id=701300000003Ssh
--------------------------------------------------------------------------
