From owner-freebsd-questions Thu Jan 1 13:40:20 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA10711 for questions-outgoing; Thu, 1 Jan 1998 13:40:20 -0800 (PST) (envelope-from owner-freebsd-questions) Received: from alpha.sea-to-sky.net (sreid@sea-to-sky.net [204.244.200.240]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA10705 for ; Thu, 1 Jan 1998 13:40:16 -0800 (PST) (envelope-from sreid@sea-to-sky.net) Received: from localhost (sreid@localhost) by alpha.sea-to-sky.net (8.8.7/8.7.3) with SMTP id NAA29136; Thu, 1 Jan 1998 13:41:08 -0800 Date: Thu, 1 Jan 1998 13:41:08 -0800 (PST) From: Steve Reid Reply-To: Steve Reid To: Michael Graffam cc: questions@FreeBSD.ORG Subject: Re: HACKED (again) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > BSD-derived Unixes have features to prevent such cloaking, by preventing > > everyone (even root) from changing important data. > > Yeah, this might be true (I havent looked into the mechanisms of this, > are we sure that an attacker can't modify the files through an indirect > means?) There are indirect ways of doing it, but they can be prevented... An attacker could unmount the filesystem, change it by messing with the disk device, then re-mount it. This only works when securelevel is 1. When securelevel is 2, the disk devices are read-only whether mounted or not. More likely, the attacker would find a system binary or script that is used _before_ securelevel is set, and modify it so that the trojans take over the system as soon as it is rebooted. This is only possible if the sysadmin forgets to "chflags schg" something. Another possibility is that the attacker would trick the system into lowering the securelevel. This means finding a hole in the kernel or init, which is probably a lot harder than finding a hole in a setuid program. All in all, securelevel is a very well thought-out feature of 4.4 BSD. > However, I dont see how this will necessarily help you against files > that need to get changed, just as log files and utmp Log files can be set append-only. I'm not sure about wtmp/utmp. > This is a good point though, it might be wise to start shipping FreeBSD > with important files locked up as the default. It has been a while since I last used FreeBSD; I'm stuck with wimpos95 for the moment. Last time I used it (2.0.5 - 2.1.7), it _did_ have a lot of binaries set immutable, but left securelevel at 0 by default. (OpenBSD on the other hand, sets securelevel to 1 by default, but doesn't set anything immutable. *shrug*) Anyone interested in setting up non-zero securelevel (I think the variable's full name is kern.securelevel, set by sysctl) should read the man pages for init, chflags, sysctl, and probably others. There are probably other sources of info around the web. The freebsd-security list archives might have some info. Securelevel is a good reason to choose *BSD over Linux in any environment where security is a concern. As far as I know, Linux doesn't have any equivalent security features.