From owner-freebsd-hackers  Mon Jul 26 10: 6:27 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91])
	by hub.freebsd.org (Postfix) with ESMTP
	id CC20614BD4; Mon, 26 Jul 1999 10:06:24 -0700 (PDT)
	(envelope-from nate@mt.sri.com)
Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA28404;
	Mon, 26 Jul 1999 11:04:48 -0600 (MDT)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id LAA19285; Mon, 26 Jul 1999 11:04:47 -0600
Date: Mon, 26 Jul 1999 11:04:47 -0600
Message-Id: <199907261704.LAA19285@mt.sri.com>
From: Nate Williams <nate@mt.sri.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: chris@calldei.com
Cc: Nate Williams <nate@mt.sri.com>,
	Dominic Mitchell <Dom.Mitchell@palmerharvey.co.uk>,
	jkoshy@FreeBSD.ORG, hackers@FreeBSD.ORG
Subject: Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
In-Reply-To: <19990726120144.E85663@holly.dyndns.org>
References: <19990726054037.D79022@holly.dyndns.org>
	<199907261116.EAA43920@freefall.freebsd.org>
	<19990726132132.B78403@voodoo.pandhm.co.uk>
	<199907261652.KAA19121@mt.sri.com>
	<19990726120144.E85663@holly.dyndns.org>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > > > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables
> > > > in FreeBSD.
> > > 
> > > But the point being made is that they are not ignored for executables
> > > which have no read access.  And from there, read access can be gained,
> > > because at that point, you have code running in the process's address
> > > space.
> > 
> > That's right.  In other words, there really is no way of protecting
> > executable files from being read if someone is motivated enough.
> > 
> > And, in an open-source OS like FreeBSD, it's not a viable solution in
> > any case....
> 
>    The only option, as I've mentined previously in this thread,
> that I can think of, would be to have an option when building
> various linker code to disable searching in $LD_LIBRARY_PATH if
> the library being looked for is in the standard library paths.

Except that's only *one* of the ways.  There's still ptrace and /proc,
so you'd have to hunt them down as well.  However, assuming you've
hunted them all down, you may be removing useful functionality from the
system that is currently used, so it's not worth it.

SEF's solution of doing a 'setuid(getuid());' is a good solution that
solves the problems listed, and doesn't require any modifications to the
system.


Nate


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