From owner-freebsd-hackers Wed Jul 15 14:09:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16472 for freebsd-hackers-outgoing; Wed, 15 Jul 1998 14:09:55 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fledge.watson.org (root@COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16464 for ; Wed, 15 Jul 1998 14:09:52 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id RAA16485; Wed, 15 Jul 1998 17:09:29 -0400 (EDT) Date: Wed, 15 Jul 1998 17:09:28 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Matthew Hagerty cc: hackers@FreeBSD.ORG Subject: Re: Protecting data in memory In-Reply-To: <3.0.3.32.19980715153323.00733ab8@wolfepub.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 15 Jul 1998, Matthew Hagerty wrote: > Is there any way to protect a programs memory space from all users, even > root? I am developing an encryption program that has to run as a daemon. > Upon start-up the program would prompt for the key, then slip into daemon > land. If the server is compromised (root access is gained) can I prevent > the cracker from reading the program's memory and gaining access to the key > data? As long as I can keep the key secure, the data should be safe (I'm > using IDEA in chain-block mode). I'm currently writing the program in C. > > If this is not possible (protecting the key), then can someone shed some > light on how I can protect sensitive data on an on-line machine? I know, I > know, but this data "has" to be on-line for processing that happens all day > long. There was discussion on freebsd-security recently about using the immutable flag to prevent debuggers/etc from attaching to processes exec'd from the file. I think this is mis-use of the immutable flag, and instead recommended a flag specifically implying process protection when running -- this would have several effects, including: 1. Preventing core dumps to disk for the process 2. Preventing debuggers from attaching to the process 3. Making /proc access to its memoryspace/etc disabled (sort of 2) 4. Preventing ktrace/truss from attaching to the process 5. Limiting signal delivery to the process (to prevent premature exit, etc). 6. Other things here? This might be good for audit daemons, key/token managers, etc. I was thinking of implementing this some time in the next few weeks -- if there are any items missing from the list above, please let me know... 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 freebsd-hackers" in the body of the message