Bearing in mind the issues:


[http://www.redteam-pentesting.de/adv...a-2005-15.txt]


AND Theo's attitude ,


"Sorry, we are going to change nothing. Securelevels are useless."




Why can't we save OpenBSD's securelevels? I have great affinity
for the concept of securelevels on OpenBSD. I believe they should
continue to be a core feature in OpenBSD.


The weaknesses within OpenBSD's securelevels and the possibility that
Theo may remove them entirely from OpenBSD , suddenly , and at a time of his
choosing , has disturbed me greatly.


Am I the only one who feels that the concept behind having securelevels
is sound and useful? Is there no way that OpenBSD's securelevels can be
fixed? Is there no way that OpenBSD's securelevels can be rewritten? Is
there no way that OpenBSD's securelevels can be re-designed?


Are securelevels not being fixed due to a lack of money? Are there not
already enough talented people within the project to create
conceptually-secure securelevels?


I personally feel that securelevels should be made to work securely on
OpenBSD even if they do not work securely on any other OS on the planet.
It could be a defining feature of OpenBSD , something that all other OS's
were not able to achieve.


I believe that OpenBSD securelevels are worthy to be kept.


I do not believe that these issues have been made clear to all users
of OpenBSD. It is my hope that many users will care and will wish
to have a choice before securelevels are removed from OpenBSD. From
Theo's published comments , I believe his stance is clear. I hope he
will reconsider.



Best Regards , An Odd User.

Anonymous wrote:
> Bearing in mind the issues:
>
> [http://www.redteam-pentesting.de/adv...a-2005-15.txt]
>
> AND Theo's attitude ,
>
> "Sorry, we are going to change nothing. Securelevels are useless."
>
....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.

Better read this advisory again:

'While protecting data effectively against permanent tampering, the term
"Securelevels" should not contain the word secure. Securelevels do not
protect against system compromise and provide only limited security. To
restrict access to a system a more secure and flexible approach like
OpenBSD's systrace[5], FreeBSD's MAC Framework[6] or SELinux[7] should
be used.'

It makes no matter how over-engineered my multi-tumbler, time-controlled
lock on my steel-plated front door is, if the cat-flap cut into it
allows me to turn the lock from the inside.

Assuming the securelevels are a panacea of any kind is a mistake. It
sounds like further assuming that the current model can salvaged,
especially when there are better tools at your disposal, is tilting at
windmills.

Better learn systrace if you really care about this. Either that, or
come up with a design that magically fixes this problem.

On Feb 20, 3:29 pm, Anonymous <nob...@mixmin.net> wrote:
> Why can't we save OpenBSD's securelevels? I have great affinity
> for the concept of securelevels on OpenBSD. I believe they should
> continue to be a core feature in OpenBSD.
>
> The weaknesses within OpenBSD's securelevels and the possibility that
> Theo may remove them entirely from OpenBSD , suddenly , and at a time of his
> choosing , has disturbed me greatly.

securelevel isn't going anywhere.

In article <cf740a7a8b13b4684647273fbadd4882@anon.mixmaster.m ixmin.net>,
Anonymous <nobody@mixmin.net> wrote:
>Why can't we save OpenBSD's securelevels? I have great affinity
>for the concept of securelevels on OpenBSD. I believe they should
>continue to be a core feature in OpenBSD.

I'm afraid you're quite alone there.

>Am I the only one who feels that the concept behind having securelevels
>is sound and useful? Is there no way that OpenBSD's securelevels can be
>fixed? Is there no way that OpenBSD's securelevels can be rewritten? Is
>there no way that OpenBSD's securelevels can be re-designed?

I'm afraid you're the only one. I fail to see any actual uses for securelevels
that make any sense.

If you need the kind of security for which securelevels would make sense,
then they will get in the way of any maintenance operation. Basically,
securelevels mean you cannot do, even as root, any patch operation without
being physically present, since you have to reboot to single mode to be
able to do anything useful with your filesystem. That's assuming you're using
securelevels for total lockdown. If you don't, the securelevel concept is
useless, anyways. There will always be `root accessible' holes on your
machine in any case. Forget about changing any disks as well, or even
mounting new stuff. There's a whole lot of useful, sometimes security-critical
things, you no longer will be able to do with securelevels.

Securelevels are not sound. To a vast extent, anything that changes the
security model of basic unix is not sound. This security model works because
it is simple: users, root, rest of the world. As soon as you add intermediate
shades, there will be some issues. See linux capabilities and how they screwed
sendmail. See how far securelevels have gone since they were introduced.

securelevels are a brain-fart. Nice new concept that makes sense on paper.
Try using them for anything real, and cry.

People who need securelevels-like capabilities get them in a smart, physical
way. You want append-only files ? send your log to another machine that can't
be tampered with !

Marc Espie <espie@lain.home> wrote:
>
> If you need the kind of security for which securelevels would make sense,
> then they will get in the way of any maintenance operation. Basically,
> securelevels mean you cannot do, even as root, any patch operation without
> being physically present, since you have to reboot to single mode to be
> able to do anything useful with your filesystem. That's assuming you're using
> securelevels for total lockdown. If you don't, the securelevel concept is
> useless, anyways. There will always be `root accessible' holes on your
> machine in any case. Forget about changing any disks as well, or even
> mounting new stuff. There's a whole lot of useful, sometimes security-critical
> things, you no longer will be able to do with securelevels.

I tried increasing the securelevel on one of my workstations some
time ago, just to see that I was not able to get any S.M.A.R.T.
related information from the hard disk. securelevel does not improve
the security of the system, but makes it more difficult to manage.
S.M.A.R.T. monitoring is certainly a critical security feature...
(e.g., what happens if one of our... we say... soekris embedded
computers is running a standard -non enhanced availability- 2.5" HDD?
We need to know when something is going wrong before data is lost!)

I certainly agree with Marc, (the highest) securelevel certainly
disables some security critical features without really increasing
security.

> Securelevels are not sound. To a vast extent, anything that changes the
> security model of basic unix is not sound. This security model works because
> it is simple: users, root, rest of the world. As soon as you add intermediate
> shades, there will be some issues. See linux capabilities and how they screwed
> sendmail. See how far securelevels have gone since they were introduced.

Access control lists are sometimes useful (and required on corporate
systems) but certainly they should be a part of the security model
adopted by the operating system, not just an add-on. Sometimes, I
miss the fine-grained access control lists provided, we say, by OpenVMS,
but I certainly understand why these security mechanisms are not being
implemented in OpenBSD.

> securelevels are a brain-fart. Nice new concept that makes sense on paper.
> Try using them for anything real, and cry.
>
> People who need securelevels-like capabilities get them in a smart, physical
> way. You want append-only files ? send your log to another machine that can't
> be tampered with !

Indeed, that is an approach that fits (and works) on the Unix security
model better than securelevels or ACLs. A security model must be as
simple as possible to work reliably.

Igor.