From owner-freebsd-hackers Thu Aug 20 16:41:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA20038 for freebsd-hackers-outgoing; Thu, 20 Aug 1998 16:41:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA20022 for ; Thu, 20 Aug 1998 16:41:10 -0700 (PDT) (envelope-from bright@www.hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.8.8) with SMTP id TAA28755; Thu, 20 Aug 1998 19:40:39 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Thu, 20 Aug 1998 19:40:39 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Mike Smith cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Trapping memory In-Reply-To: <199808201558.PAA00613@dingo.cdrom.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 baring physical access to the machine couldn't you compile in the secureflags option? then make sure to chflags the kernel, and startup scripts properly. btw, perhaps a sysctl that could be set but not cleared in securemode to suppress lkm loading. properly chflag'd startup scripts could load lkms, then set the flag to prevent a kernel trojan/virus lkm from being loaded. Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com -- There are operating systems, and then there's BSD. -- http://www.freebsd.org/ On Thu, 20 Aug 1998, Mike Smith wrote: > > Is there some way to trap or detect when some other program is trying to > > read memory used by another program? > > You could implement a kernel extension to provide this support. > > > For example, I have an encryption/decryption daemon that holds its key in > > memory. I have been told that there is really no way to protect the memory > > used by the daemon in the case of a root compromise. However, if I could > > somehow detect another program trying to access my daemon's memory space, > > then I could have the daemon dump the key and shutdown. > > > > Any insight would be greatly appreciated. > > A root compromise would be able to defeat the detection mechanism. > > You could increase the difficulty of recovering the key slightly by > obfuscating its storage, but protecting it completely would require > kernel modifications which could be reversed/removed/faked around by a > sufficiently persistent attacker. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message