From owner-freebsd-questions Thu Jan 1 14:32:28 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA13861 for questions-outgoing; Thu, 1 Jan 1998 14:32:28 -0800 (PST) (envelope-from owner-freebsd-questions) Received: from mhv.net (root@spice.mhv.net [199.0.0.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA13855 for ; Thu, 1 Jan 1998 14:32:25 -0800 (PST) (envelope-from mgraffam@mhv.net) From: mgraffam@mhv.net Received: from localhost (qripto@port108.mhv.net [206.229.41.36]) by mhv.net (8.8.5/8.7.3) with SMTP id RAA21470; Thu, 1 Jan 1998 17:32:17 -0500 Date: Thu, 1 Jan 1998 17:26:43 -0500 (EST) X-Sender: qripto@localhost To: Steve Reid cc: Michael Graffam , 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 -----BEGIN PGP SIGNED MESSAGE----- On Thu, 1 Jan 1998, Steve Reid wrote: > 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. Yeah, _that_ is a clever little idea. I wouldnt have thought of that one :) > 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. Yeah, I'd consider this a dead end.. > > 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. Yeah, but append-only mode isnt necessarily the greatest either.. but this is really a different issue.. one that centers around how much one trusts the audit trails. > 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. Yeah, there is another resource that covers this.. I wish I still had the URL.. it was a list of links and dox on which programs and features are of concern for site security. I'll run a search and see if I can re-find it. > 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. I dont think there is a direct counterpart in Linux to securelevel either, but I think that one could set things up to act like various securelevel states. Linux's ext2 filesystem has security stuff too. The chattr command will flip the bits for a file's attributes. You can set it to stuff like append-only writes, locked access (like immutability), secure deletion (blocks are zeroed out if the file is erased) and there are hooks in the code for automatic compression and I think crypto as well (but these features arent in the stock ext2, as far as I know.. I havent checked in awhile).. so the file attributes are similar.. though I havent really put Linux's attribs to the flame and tested them.. I know that BSD's work. So, if I had to pick a system, I'd pick BSD too for security.. Michael J. Graffam (mgraffam@mhv.net) http://www.mhv.net/~mgraffam -- Philosophy, Religion, Computers, Crypto, etc "Enlightenment is man's emergence from his self-incurred immaturity. Immaturity is the inability to use one's own understanding without the guidance of another. . .Sapere aude! Have the courage to use your own understanding!" - Immanuel Kant "What is Enlightenment?" -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBNKwYJwKEiLNUxnAfAQHs4gP/eOs9tp32KGJDTeIcMpfy4R3NBDpPjGKt /vUX6GTW4gZO9AfUI4uqoEOriA1an/L1KePxbOz8JwcGNdmEaZ02P5KkWQByeu9Z WCHSXQ1sPxZRKqPUQR8gXSUJwmoWA4iG92mSB10ad/hm33iUwidL/Es1OQzf8nh4 fcxTXvhjonI= =Gh1w -----END PGP SIGNATURE-----