From owner-freebsd-hackers Wed Jul 15 14:56:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22712 for freebsd-hackers-outgoing; Wed, 15 Jul 1998 14:56:36 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22693 for ; Wed, 15 Jul 1998 14:56:32 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id RAA07159; Wed, 15 Jul 1998 17:55:54 -0400 (EDT) (envelope-from luoqi) Date: Wed, 15 Jul 1998 17:55:54 -0400 (EDT) From: Luoqi Chen Message-Id: <199807152155.RAA07159@lor.watermarkgroup.com> To: joelh@gnu.org, matthew@wolfepub.com Subject: Re: Protecting data in memory Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Is there any way to protect a programs memory space from all users, even > > root? > > No. root always has access to all memory space. Consider: If it were > otherwise, root could just patch the kernel and gain whatever access > was needed. Actually, if you raise the securelevel to 1 or above, not even root can access kernel memory space (see init(8)). It is still possible to access user process memory space through procfs -- procfs doesn't yet check securelevel before granting access to mem file. To disable procfs, remove PROCFS option from your kernel config file (you may also want to compile file systems like NFS into the kernel instead of lkms), make a new kernel. Remove /proc entry from /etc/fstab, raise securelevel at the very beginning of your /etc/rc file. Boot from the new kernel, and you should be all set. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message