-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Douglas" == Douglas Wade Needham <cinnion@ka8zrt.com> writes:
    Douglas> I hope folks don't take this wrong, but I see this as
    Douglas> potentially opening a can of very nasty worms (of the
    Douglas> fishing kind).  If we did such a thing, we would have to
    Douglas> test against not only kern.securelevel, but the knob for x,
    Douglas> y or z.  Worse, in some situations, we may find that have

  No, that's not how it would be implemented.
  You would have knob x, y and z.

  The test would now be simpler, instead of:
      if(securelevel > FOO) {
      }

  it would be:

     if(knob_x) {
     }    

  and
	update_securelevel(int value) {
		if(value > FOO) {
			 set-knob-x;
			 set-knob-y;
			 set-knob-z;
		}

  The comments about SGI (and VMS) are relevant -- places to learn from.

  But, this isn't about what a USER or PROCESS can do, it's what the
system will let ALL USERS do.  Many of us want securelevels great than
2, but it's clear that none of us know what a monotonically increasing
value for this is.
  For instance I think that many of us want securelevel=1 +
feature-Y-that-is-in-securelevel=2. 

   (Sure, one of the knobs might be: only-superuser-can-bind<1024, but
   that would be system wide)

    >> of course we can always make it a compile-time option whether we
    >> want to go the securelevels-route, lots-of-knobs-route, or the
    >> above described hybrid-route.

    Douglas> Gack!  I can just see the code...just the type of
    Douglas> conditional compilation code I hate to see when I am trying
    Douglas> to track down a problem, and am almost certain to find
    Douglas> contains my bug.

  #define knob_x (securelevel > FOO)

    Douglas> one.  This means we should stick with just
    Douglas> kern.securelevel, as it has existed since Mike, Kirk and
    Douglas> Keith put it into what became 4.4.  No additional sysctl
    Douglas> knobs and no adding in some compile-time option which
    Douglas> allows for it to be decreased.

  okay. Make sure that you also stick with the the kind of networking
that you had at the time --- 56k leased lines running things that aren't
IP! :-)

  The reason why the mechanisms of yesteryear don't satisfy us anymore
is because the threat model is now more complex.

    Douglas> BTW...in every single one of those BSD servers at CSI, we
    Douglas> had kern.securelevel at a minimum of 1 for all
    Douglas> non-development servers, and it never really caused us
    Douglas> problems when debugging things like suid apps.  Indeed, as

  I want to set securelevel>1 for ALL desktops, including development
servers.  Those 1000 spams that your mail server just received while you
were reading this were sent from "desktops" (non-production servers)
from one particular vendor with a BSD networking stack that has
the equivalent of securelevel==-1 all the time.

  I don't run a NetBSD desktop anymore, (only servers).

  Can one even run X with securelevel=1 yet? I kept maintaining a patch
that let me do that on my laptop, and it was a pain.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBQ9kq7YCLcPvd0N1lAQIPVwgAnYhaOhd/vyGUmm4pUwC3XZxJNx97bkmx
Z26+MzY+YHV7ISsfI57UubrCwncasVX/JDsAJuGDxXjxy8VN6ju1qJRmV255EEHc
bk1fObahDPKs9QFV6DnAOFoHfVMBgyewd1zUVuIaog2rcZgHpIn3wMm0ENWrUdAi
F+MotQPYOnz3fmwONGBhclHW+avuUFZLCfVAPMBwHfggI+1zxv+LbIvuzayLrcSS
C0FOPzLeQqRjbPq58hBxYmcvGGZx3ZBDSws7vAw8ngzmv0pXcTFsLSA7ltToc6gR
80F27srE0iq5VLx9108c7omh1IBKym+IwZNmbdm1vbJj77Pv6gNc2Q==
=mTm0
-----END PGP SIGNATURE-----