From owner-freebsd-security Thu Oct 5 9:52:59 2000 Delivered-To: freebsd-security@freebsd.org Received: from public.bta.net.cn (public.bta.net.cn [202.96.0.97]) by hub.freebsd.org (Postfix) with SMTP id AF28B37B503 for ; Thu, 5 Oct 2000 09:52:54 -0700 (PDT) Received: from netrinsics.com([202.106.213.194]) by public.bta.net.cn(JetMail 2.5.3.0) with SMTP id jm1039dcfb7b; Thu, 5 Oct 2000 16:52:44 -0000 Received: (from robinson@localhost) by netrinsics.com (8.11.0/8.9.3) id e95GRBX07405 for freebsd-security@freebsd.org; Fri, 6 Oct 2000 00:27:11 +0800 (+0800) (envelope-from robinson) Date: Fri, 6 Oct 2000 00:27:11 +0800 (+0800) From: Michael Robinson Message-Id: <200010051627.e95GRBX07405@netrinsics.com> To: freebsd-security@freebsd.org Subject: Downgrading securelevel on remote servers Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Then they'd go change /etc/rc. You could set most of your root >filesystem, including /etc, schg, which may help, but then you'd be >making your machine almost unmanagable without console access. For >example, how would you fix this chpass bug if you couldn't access the >console and had no way to lower the securelevel, even with a reboot? The solution I came to for this problem was to use Gnu Privacy Guard to sign scripts in /usr/local/etc/secure, and a script that verified the signatures and executed them prior to the securelevel being set in /etc/rc. If you needed to do something like change the suid bit on chpass, you would write a script to do that, sign it, install it, reboot, and remove the script. The server only kept a copy of the public key (the keyring was noschg, of course). I don't need to do that anymore, though, because now I have an OOB Cisco 2509 connected to the console ports on our colocated servers. -Michael Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message