Anonyma wrote:

> Anonymous wrote:
>> Bearing in mind the issues:
>> []
>> AND Theo's attitude ,
>> "Sorry, we are going to change nothing. Securelevels are useless."

> Clever Monkey wrote:
>> ...and notice that neither of the other platforms had anything better to
>> say on the matter. Clearly no one is going to fix this broken model.
>> Theo is just not bothering to sugar-coat it.

> *** Also notice that NetBSD was found to be immune to the problems.

Clever Monkey wrote:

>To this single problem, you mean.

*** Yes , whatever NetBSD has implemented in this particular regard seems superior
to what we have on OpenBSD IMO. It would seem that NetBSD chose to act proactively
and OpenBSD chose not to. If you notice , the original article claims that this
problem had been known for some time prior to the Red Team discovery of it.

> *** Also notice that if OpenBSD had chosen to lead the way with some
> type of redesign , other OS's might have followed their lead.
>Since when?

*** Since OpenSSH. Since PF. Hasn't the evil Microsoft even incorporated some OpenBSD code?
Need more examples?

> *** There is "sugar-coating" and there is defeatism.
>A bad design is a bad design. Some things may not be worth saving.
>This is called "realism". Perhaps migrating to a better way to enforce
>policies is better.

*** "A bad design..."? From my vantage point the concept and logic of securelevels
seems elegant. If the code could have been written or integrated better are
other matters entirely IMO.

*** If you want realism , I would hazard to guess that most all OpenBSD boxes running
just now , around the world , are being actively protected by securelevels. I believe
most of these would be at securelevel 1 (or higher).

>Instead of posting this here, why not raise it with OpenBSD (perhaps via
>misc@) and get the real answer. It won't be the answer you want and it
>may come with some rather forceful explanations, but no one here can do
>anything about it.

*** As I mentioned previously , misc@ and email mailing-lists in general are
insecure and pose a number of threats to OpenBSD users. The project could set
up some clever system if they wished to , an SSL-enabled website where users
could submit possible problems (pseudo) anonymously. Maybe such a site (or sites)
could issue tracking numbers and pre-screen any critical problems that were
submitted. At present details of critical flaws travel as plaintext across the
Internet until they reach one of the project's servers.

*** Just as an additional comment , OpenSSL isn't particularly well-respected and for
a number of reasons. I believe the folks over at sci.crypt , as a group , aren't
fans of OpenSSL either. OpenBSD (and perhaps OpenSSH) would probably benefit if
the OpenBSD project wrote and maintained a separate version of OpenSSL. It would also
be nice if SERPENT-256 , TWOFISH-256 as well as SHA-256 , SHA-512 , and perhaps
Whirlpool could be added to both OpenSSH and OpenSSL.

*** "...but no one here can do anything about it."?
If the project refuses to fix things that are broken AND
refuses to provide accurate man pages , it is up to users to help
themselves. I don't like the "ostrich approach" to threat
management. Users facing threats should always be warned , forewarned
frequently means forearmed. Those relying too much on securelevels
for protection might start employing restrictive mount options instead , but
may never seek to do so if they aren't aware of the uncorrected problems
affecting securelevels.

>From my glance at
> systrace looks
>like a very complete tool. Perhaps you can specify places where
>functionality offered by securelevel is not covered by systrace or some
>other facility?

*** Habeas corpus , show me the body. I am aware of no proof-of-concept
that systrace can be used to replace the concept of securelevels effectively.

*** If the OpenBSD project's developers can't write systrace policies to emulate
the concept of securelevels , just how many average users would be able to do

*** IMO the project should either disallow the mounting of filesystems in
securelevel 2 or perhaps if it would be quicker and easier to achieve
create a new "securelevel 3" to accomplish this. "Ultra secure mode"

*** If the project is amenable to creating something like a securelevel 3 ,
they may wish to also add additional controls as relate to the "kill"
command. It is possible that the Red Team paper was not quite as
thorough as it perhaps could have been.

*** I do wish to explore what systrace has to offer at some point , but I
certainly wouldn't wish to have to attempt a perhaps herculean task like
replacing securelevels on short notice.

Regards , An Odd User.