From owner-freebsd-security Mon Sep 20 16:29: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from tusk.mountain-inter.net (tusk.mountain-inter.net [204.244.200.1]) by hub.freebsd.org (Postfix) with ESMTP id C283E15B6D for ; Mon, 20 Sep 1999 16:28:55 -0700 (PDT) (envelope-from sreid@sea-to-sky.net) Received: from grok.localnet (dialup56.mountain-inter.net [204.244.200.65]) by tusk.mountain-inter.net (8.9.3/8.8.7) with ESMTP id QAA16944; Mon, 20 Sep 1999 16:28:20 -0700 Received: by grok.localnet (Postfix, from userid 1000) id E26FB212E07; Mon, 20 Sep 1999 16:33:04 -0700 (PDT) Date: Mon, 20 Sep 1999 16:33:04 -0700 From: Steve To: Robert Watson Cc: Jobe , ark@eltex.ru, freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <19990920163304.A334@grok.localnet> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Robert Watson on Mon, Sep 20, 1999 at 12:10:34PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Sep 20, 1999 at 12:10:34PM -0400, Robert Watson wrote: > One thing I am particularly interested in seeing brought to fruition is a > way to protect key system security processes from interference--from any > other user process, even one running as root. This might be similar to > the jail code--the world being in a jail and only processes such as auditd > (possibly init?) outside of it. Processes would be unable to attach > debuggers to protected processes while securelevel was set above a certain > value, and limited in their ability to signal the processes, etc. Init used to be able to lower the securelevel and for that reason had (and still has?) some kernel code protecting it. IIRC, it was decided that Init's ability to lower the securelevel be revoked after it was discovered that the protections did not take cover procfs. The protections may still be in the kernel and might be adapted to protect other processes. Also, although you can signal Init, if it dies for any reason the system will reboot. This might be useful for security-related monitoring processes as well. Sorry, I don't have code... Not a kernel hacker. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message