On 1/28/06, Elad Efrat <elad@netbsd.org> wrote:
> like? i already said that as far as security goes there is nothing
> in freebsd i'm interested in. search the archives!

An open mind is a terrible thing to waste.

> did you look at the bsd-licensed code that is the MAC framework?
> what can you use it to achieve? have you not read my opinion on
> MAC? MAC is the last thing i want to waste my time (or see others
> waste their time) on.

I'd like to know more, but all I can't find this in the archives.=20
I've discovered you created Stephanie, and discussions about an
AES-XCBC-MAC, but no mention of mandatory access control.  Can you
link me?

Personally, I do security for a living and although I've been running
the NetBSD strain since 386BSD-0.1, I consider it to be lagging behind
other OSes when it comes to security.  I would have expected the
NetBSD developers to have thought deeply about it, and implemented
some firm and powerful foundations on which we could build
high-assurance systems, but if they have it is not apparent to the
casual outsider.

Swerving back on topic, I have noticed two camps in
thinkers-about-security.  In the first camp, we have people who think
that if it's possible to exploit, it's broken.  They cite that experts
share knowledge with the neophyte, and that today's theoretical
attacks are present in tomorrow's worm.  They think you should employ
countermeasures based on vulnerability assessments.  In the second
camp, we have people who think it's good enough to raise the bar, so
that attackers will move onto easier targets.  They say that most
attacks are script-kiddie, not customized, and likely to be stopped by
the simplest of measures.  They think that you should employ
countermeasures based on threat assessments.

I see the invocation of VMS and IRIX and the notion of
"root/su-complete" sets as the first camp.  To them I would say that
we should disable any feature that could lead to a root compromise
when running at securelevel >=3D N.  Of course this means halting the
processor, but at least nobody can get root (or modify the persistent
state, or the TCB, etc.).

Attacks only get better, and it is inevitable that we may miss some
along the way.  That's life.  Let's do our best, and look for ways to
do better.

Aside:

IMHO, leaving a complicated exploitation route is better than leaving
a simple one, and if you think about it, if understanding the exploit
is beyond the ken of a script kiddie, and you make a slight change,
they are unlikely to be able to change the exploit to handle it.=20
That's worth something too, although I couldn't tell you how much.  If
you want to label that security through obscurity, then I'll say, in
practical terms, security through obscurity is better than no security
at all.  I'd say 99% of attackers couldn't write a stack overflow if
they wanted to, and that means that 99% of the attacks against network
daemons are canned, which makes them easier to detect, if not prevent.
 Right now most of the commercial tools are doing misuse detection,
and guess what?  At the current state of the art, it works better in
several ways than having tons of unique attacks and trying to do
anomaly detection, which is basically where web application security
is right now.  Any fool can do sql injection, XSS, or a host of other
web attacks, all because they have no protection mechanisms to build
from or reuse.  And any fool can change a URL to use unicode encoding,
or make some other trivial change that changes its signature.
--
"The generation of random numbers is too important to be left to chance."
  -- Robert Coveyou -><- http://www.lightconsulting.com/~travis/
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B