Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Oct 2001 02:36:41 -0400 (EDT)
From:      Jeff Palmer <scorpio@drkshdw.org>
To:        David S Strait <basilisk@umail.ucsb.edu>
Cc:        <freebsd-security@freebsd.org>
Subject:   Re: Kern Secure Level
Message-ID:  <20011006022008.R66168-100000@Scorpio.drkshdw.org>
In-Reply-To: <Pine.GSO.4.21.0110052303250.18017-100000@bergman.umail.ucsb.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
In my opinion,    secure levels is nly a deterrant.  In fact,  most people
don't even use it properly.

The idea of secure levels is to set certain files as immutable  (not even
root or superusers can change the file.)

The problem with it is twofold:

1) Most people fail to set the proper binaries as immutable,  to stop them
from being trojaned in the even of a succesful hack.

2)  FreeBSD doesn't have the appropriate files set as immutable by
default, nor after a buildworld.  So unless you specifically set the files
immutable,  securelevels is pointless.   especially when you factor in the
fact that..   the intruder already has access to your mahine when
securelevels comes into play.   At this point,  a foresics diagnostic
should be performed to gain all available data about the intrusion.  and
then the machine should be formatted and a fresh OS installed.

For those who don't know which files I'm talking about,  when it comes to
securelevels.   A major one would be /etc/rc.conf.

If the intruder has root access on your machine,  all he has to do is edit
/etc/rc.conf  to set the securelevel to -1 and upon next reboot,  your
securelevels didn't do anything but delay his final outcome.

I personally have all binaries that deal with passwords and remote
authentication set immutable.    My feeling is this:  they already have
access to my machine,  why allow them to trojan ssh, ftp, telnet, login,
etc etc  and give them access to OTHER remote machines..  simply because
mine was vulnerable.


Securelevels will not stop your machine from being hacked or even
attacked.  It may,  with proper configuration, help stop your machine from
being the reason some other machine was hacked.

Perfect example was the recent apache.org hack.


An ISP was hacked  and ssh was trojaned.  An apache.org employee  (or
developer,  I forget) then logged into the webserver.  Upon doing so, the
trojaned ssh client gave the attacker the password.   If securelevels had
been implemented,  the ISP's machine would have still been compromised,
however  the immutable "ssh"  would not have given the intruder access to
apache.org


Anywho,  sorry for the long post..  all in all,  to average joe blow
FreeBSD user,  no  securelevels is of little value.   To a security
concious admin,  who takes the time to research it,  and set the proper
permissions..  securelevels CAN stop your macine from passing certain
information on to attackers.



Another thing to consider..

A lot of newbie  (please,  no flames if this includes anyone reading this
list)   a lot of newbie admins will read about securelevels,   and make
the entire /bin /sbin and other directories immutable.   This is a BAD
THING!

One of the easiest ways to tell if your machine has been compromised,  is
by using third party utilities to create checksums of all important files
on the system.  If (in the example above)  you have been compromised,  and
did NOT have ssh immutable,  but DID have a valid checksum of the file on
record.  the checksum would change,  and that would be an immediate clue
that you have a security breach.

If you set entire directories of files immutable,  you effectively
eliminate that method of intrusion detection.  (Most machines that have
been hacked,  are noticed because of this method.. or by other admins
emailing administrators asking why there was a DoS launched or port probes
from your machine.  Wouldn't you prefer to know BEFORE your machine is
used to launch other exploits?)


Jeff Palmer
scorpio@drkshdw.org




On Fri, 5 Oct 2001, David S Strait wrote:

>
> There is a little discussion about kern secure level in the 'man init'
> page, but its somewhat brief.
>
> On Kern level 1, I couldn't get X-windows to work so I wanted to lower
> it.  (As it turned out later, this was the solution, and X-win worked.)
>
> I'm running FreeBSD 4.4 REL and basically:
> when kern_securelevel="0" in rc.conf, it just hops up to 1???????
> But if you leave it: kern_securelevel="-1" or kern_securelevel="1", then
> it will go to -1, 1 respectively.  Why on 0 does the level get bounced to
> 1?
>
> Is there a *serious* security issue with kern levels -1 and 0?
>
>
> Thanks.
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message
>
>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011006022008.R66168-100000>