From owner-freebsd-security Fri Sep 17 16:15:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id 7F8B615B23 for ; Fri, 17 Sep 1999 16:15:42 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id QAA04190 for ; Fri, 17 Sep 1999 16:12:30 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA55902; Fri, 17 Sep 1999 15:59:11 -0700 (PDT) (envelope-from dillon) Date: Fri, 17 Sep 1999 15:59:11 -0700 (PDT) From: Matthew Dillon Message-Id: <199909172259.PAA55902@apollo.backplane.com> To: Warner Losh Cc: Brett Glass , Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <4.2.0.58.19990917160519.047cc890@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <199909172208.QAA05554@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Yes. Automation would help. Today you almost have to do : chflags schg /usr/{s,}bin/* /{s,}bin/* /usr/libexec/* /etc/* /usr/lib/* :to get started, but even that leaves a few holes... : :I'd love to see an intellegent automation tool and would happily :review it. Sadly, I don't have the time to write and maintain said :tool. : :Warner At BEST I cared about two things security-wise: (1) preventing non-root users from being able to gain root, and (2) detecting those intrusions that actually manage to break through to root. Making a system reasonably secure does not equate to protecting root from itself. If someone has root, you've lost. Period. It doesn't matter whether they can modify the system or not, you've still lost. Trying to protect root from itself only prevents your security scripts from detecting the fact that you've lost. In that respect, I find chflags utterly useless and the securelevel only moderately less so. All they do is prevent the hacker from making changes that would otherwise cause his presence to be detected. I still use it to some degree -- I think a distinction should absolutely be made between raw device access and access through a filesystem, but the primary purpose of those tools is simply to create enough of a delay to be able to react to a situation. Having the schg flag and securelevel give you useful tools, but you shoot yourself in the foot if you overuse them or come to depend on them. Believe me, chflaging half the files in / and /usr to schg is a major overuse. By the time you've schg'd everything to the point where root is supposedly 'safe', you might as well have simply mounted / and /usr read-only in the first place. It would have been easier. This is what I might recommend for a poor-sysad's security: * Setup the systems * Quietly do a read-only NFS export of everything from every system to a secure security box that only one or two people can get into. * Have that box md5 (etc....) and test the files for changes, for suid bits, and so forth. Once a night, every night, and to notify you if something changes. Check system configuration files even more often - doesn't cost you a thing to check a dozen or two files on every machine once every 5 minutes! I'm going to update my security page ( man 'security' ), it's a little dated. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message