From owner-freebsd-security Tue Jul 29 05:32:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA08434 for security-outgoing; Tue, 29 Jul 1997 05:32:46 -0700 (PDT) Received: from cyrus.watson.org (robert@cyrus.watson.org [207.86.4.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA08423 for ; Tue, 29 Jul 1997 05:32:41 -0700 (PDT) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id IAA06017; Tue, 29 Jul 1997 08:32:21 -0400 (EDT) Date: Tue, 29 Jul 1997 08:32:21 -0400 (EDT) From: Robert Watson Reply-To: Robert Watson To: Vincent Poy cc: Brian Buchanan , freebsd-security@FreeBSD.ORG, JbHunt , "[Mario1-]" Subject: Re: securelevel (was: Re: security hole in FreeBSD) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 28 Jul 1997, Vincent Poy wrote: > On Mon, 28 Jul 1997, Brian Buchanan wrote: > > =)Uh, that would defeat the purpose of securelevel. It's not supposed to be > =)possible to ever lower it, except when dropping into single-user mode, and > =)even allowing init to do so in that instance is risky IMHO - a few months > =)ago I reported a hole, which I believe was fixed, that made it possible to > =)lower the securelevel by attaching a debugger to init. Even though that's > =)plugged now, it's still possible that there's another way to fool the > =)kernel into thinking that process 1 is requesting that securelevel be > =)lowered. > > Anything is possible since nothing is unhackable. Would running > init at securelevel 2 and then have it reboot multi-user at a lower level > be possible? I disagree with the assertation that nothing is unhackable. My toaster is unhackable. :) Depending on how you define hack, of course. But in a similar vein: you say you have been carefully following the latest version releases, and patching all known bugs. That is not sufficient. A site needs a good security policy as well as patching known bugs. For example, you should have been using ssh the entire time, and have copied the public keys for the hosts to your client machine using sneaker-net. Sending any unencrypted data to/from a host, especially sensitive information like the root password, is an extremely bad idea. Similarly, careful analysis of the trust relationships between the machines and accounts on the machines is important -- constructing a bad DNS structure can invalidate your whole security design, as if DNS is corrupted, all the .rhosts stuff is vulnerable. Ideally, you would only use .rhosts in combination with SSH, and then make sure that the appropriate keys are in /etc/ssh_whatever, and deny connections that did not match the predefined keys of all hosts. Key distribution is one of the big downsides to SSH, but floppy disks can help here. Applications like web servers may themselves represent no immediate or known security problems, but often-times web servers use third party CGI programs, available publicly in source, or written by a third party for the web server. Many web programs are notoriously sloppy (or ignorant), and this has not been helped by the release of a number of CGI programming books that haven't even touched on the issue of security. It has been shown time and time again that greater access for an attacker increases risk, and most CGI bugs allow shell access to the host, albeit as www or nobody. Even those are problematic. And once someone is in to the system, they can get around simple solutions like disabling inetd. In 15 seconds, I can compile and run a daemon that lets me back into an account on a higher port number, and unless you know your tools are good, and how to use them, you won't be able to tell. I certainly won't appear in the logs. :) In the case of someone else's machine, you probably can't do anything to get rid of the CGI problems, so that really leaves you with just minimizing the risks in the OS. You've already touched on SUID programs -- as many as possible should be disabled. If you have console access, just disable root also, as you can login as root directly. Most programs do not require suid, if you don't mind administrating as root. Su'ing to root is clearly a risky activity, especially if you're logged in unencrypted. Setting a high secure-level, as well as mounting all file systems w/o setuid support, can make a big difference. Mount all file systems but root as nodev, and things should move along some also. Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Security Research, Trusted Information Systems http://www.tis.com/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@tis.com http://www.watson.org/~robert/