Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Jun 1998 11:51:56 -0400 (EDT)
From:      Robert Watson <robert@cyrus.watson.org>
To:        Niall Smart <njs3@doc.ic.ac.uk>
Cc:        Nicholas Charles Brawn <ncb05@uow.edu.au>, security@FreeBSD.ORG
Subject:   Re: non-executable stack?
Message-ID:  <Pine.BSF.3.96.980624114741.17202J-100000@fledge.watson.org>
In-Reply-To: <E0yoqEs-0002io-00@oak67.doc.ic.ac.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Jun 1998, Niall Smart wrote:

> It would be nice to have a filesystem non-executable-stack flag so that
> it could be enabled/disabled on a per file basis.  Another option would
> be to only turn it on for set[ug]id executables.  There are a number
> of other "features" like this that would be useful, for example the
> ability to specify that only printable ascii characters can appear in
> the arguments or environment of a process before it can exec another.
> I haven't checked if its possible to write shellcode using just plain
> ascii characters,  if you can then this is obviously worthless, but I'd
> be surprised if it's possible.

I don't know if the "for setuidgid" only flag would be useful -- many
daemons don't run setuid/setgid, but are still sources of vulnerability.

What I'd like to see is a chflags flag PROTPROC that would have the
features some were trying to associate with SCHG -- that is, this flag
would provide extra protection for processes derived from an exec of the
file in question.  In a high secure level, PROTPROC would prevent
ptrace,ktrace from attaching to the process, and might also prevent signal
delivery from processes with the same uid that might result in termination
(for example).  To prevent some unfortunate other effects, I would be
tempted to make the flag removable and settable only when securelevel > 0.

This would allow syslogd to be protected from signals, debugging, append
to an append-only file, and have its binary be immutable.

This would also allow for things such as an audit lkm hooking into an
audit daemon.  I'm starting to put together such a beast, and have a brief
description at http://www.watson.org/fbsd-hardening/audittool.html.

My current project is lkm token extensions for
authorization/authentication (almost completed an initial implementation),
which may be useful for distributed file systems (such as AFS, Coda, etc),
and could be used to store IPsec keying material and so on.

I hope to have a test run of the lkm available for download by the end of
this upcoming weekend, along with modifications to the kerberos library to
use it next week.

  Robert N Watson 

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
SafePort Network Services             http://www.safeport.com/
robert@fledge.watson.org              http://www.watson.org/~robert/


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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980624114741.17202J-100000>