Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Oct 2001 12:52:17 -0700
From:      "Crist J. Clark" <cristjc@earthlink.net>
To:        Jeff Palmer <scorpio@drkshdw.org>
Cc:        David S Strait <basilisk@umail.ucsb.edu>, freebsd-security@FreeBSD.ORG
Subject:   Re: Kern Secure Level
Message-ID:  <20011006125217.A350@blossom.cjclark.org>
In-Reply-To: <20011006022008.R66168-100000@Scorpio.drkshdw.org>; from scorpio@drkshdw.org on Sat, Oct 06, 2001 at 02:36:41AM -0400
References:  <Pine.GSO.4.21.0110052303250.18017-100000@bergman.umail.ucsb.edu> <20011006022008.R66168-100000@Scorpio.drkshdw.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 06, 2001 at 02:36:41AM -0400, Jeff Palmer wrote:
> In my opinion,    secure levels is nly a deterrant.  In fact,  most people
> don't even use it properly.

True.

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

Making files immutable is only part of it. No more KLDs or write
access to /dev/mem.

> 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.

Yep.

> 2)  FreeBSD doesn't have the appropriate files set as immutable by
> default,... [snip]

This is actually the same point.

> 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.

This does not necessarily stop anyone from collecting passwords. The
easiest thing to do is to place a trojaned sshd (or telnetd, whatever)
in /tmp/sshd, kill the running one, and manually start the one
/tmp/sshd. The path will show up wrong in ps(1) output? A program can
easily lie about that. It is also possible, but not easy, to grab
passwords from the process as it runs without actually modifying it on
disk. There are also some very interesting attacks possible on your
immutable files on things like /usr/sbin/sshd and /usr/libexec/telnetd
since you can still potentially mount and umount /usr (just how
interesting depends on whether you are at securelevel = 1 or > 1). For
anything going over the network in clear text, you can just run a
sniffer and not worry about trojaned binaries at all.

The minimum set of files that must be immutable to make a box
reasonably secure goes far beyond /etc/rc.conf. You need to make _all_
files executed with root privs before the securelevel is raised
immutable. A quick look at /etc/rc shows this includes ones you
expect,
	/bin/sh
	/sbin/fsck
	/sbin/mount
	etc.

And some others that don't immediately seem obvious,
	/bin/chmod
	/bin/rm
	/bin/stty
	/sbin/dmesg,
	/usr/bin/awk
	/usr/bin/chflags
	/usr/sbin/chown
	etc.

> 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.

Exactly. It will not stop a compromise. No matter what you do with
securelevels, if you have a telnetd from before July of this year
listening, someone can root your box. What it can do is make it
difficult for the attacker to take complete control of the box and
cover his tracks before he is detected. Difficult, but not
impossible.
-- 
Crist J. Clark                           cjclark@alum.mit.edu
                                         cjclark@jhu.edu
                                         cjc@freebsd.org

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?20011006125217.A350>