From owner-freebsd-security Thu Jun 17 21:52:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 72DBF14C9C for ; Thu, 17 Jun 1999 21:52:35 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id XAA15397; Thu, 17 Jun 1999 23:52:27 -0500 (CDT) From: Joe Greco Message-Id: <199906180452.XAA15397@aurora.sol.net> Subject: make world clobbers (was Re: some nice advice...) To: synk@swcp.com Date: Thu, 17 Jun 1999 23:52:27 -0500 (CDT) Cc: security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > There is little point in chmod'ding an executable to 0 on a free OS where > > the executables can be retrieved from any convenient FTP site. In fact, > > some utilities may retain their usefulness in some lesser manner... or > > you may wish to run them as root... or for example, doing a chmod 0 on > > /usr/bin/login may not be too slick. > > > > You want to remove the privilege. That's all, really. > > > > Otherwise you get into the slippery slope of "why don't you chmod 0 this > > other random non-suid executable that nobody on this system will ever need", > > and that wasn't the point. The point was to remove likely security holes > > opened by suid or sgid executables on application-server-platform class > > machines where no "normal user" would lose by being unable to run them, > > and then applying some really mean-ass schg flags. > > The main reason I'd chmod 0 an executable is to remove it from the path > entirely. Unless I'm mistaken, root can execute a mode 0000 file anyway. You are mistaken. Thankfully. Root had better damn well never execute anything if there is the slightest amount of doubt. > On a related question, what do you all do about make world overwriting all > your chmod changes? I'm constantly plagued by this and other things like > sendmail overwriting qmail's sendmail symlink. Is the only answer to write > a custom fixit script? By definition, one isn't too interested in running "make world" on an application-server-platform class machine. You're looking for a platform on which to run some application, and about the only thing you'll ever need to patch would be the kernel. Anything else (bugs in userland) is merely an annoyance that you can live with because you didn't need any of that stuff anyways. And if you _do_ need to upgrade, you'll do it from a binary distribution, not from source, because you can't really afford to have your application server offline for the unnecessary luxury of building the world. But to answer the question you're sort of asking, yes. If I make more than half a dozen custom changes to any system, I have to ask myself what the hell I'm doing wrong. I have a set of scripts that I run to do things such as baseline customizations (addition of admin accounts, basic rc.conf configuration, nameserver setup, ntp setup, inetd setup, etc), standard port installation (shells, utils, etc), and several other things. Since things such as firewalls and fileprotections need to be negotiated on a per-application basis, these take a little more work. Another script to install the service in question, and all should be done... with zero manual piddling around. If I have to diddle with a system, there's a good chance that I might not do it the same way next time, and that's a bad thing. So I work very hard to minimize any such efforts. If I do need to upgrade a system, though, I remove the schg flags in single user, install the new distribution, and then re-run all my system building scripts, all of which should do the right thing for whatever situation they find themselves in. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message