From owner-freebsd-questions@freebsd.org Thu Oct 12 21:07:03 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D463E34AA6 for ; Thu, 12 Oct 2017 21:07:03 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 0CAF4671F5 for ; Thu, 12 Oct 2017 21:07:02 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 8158E3AF83 for ; Thu, 12 Oct 2017 14:07:00 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Re: Install-time "hardening" options In-Reply-To: <12891.128.135.52.6.1507831901.squirrel@cosmo.uchicago.edu> Date: Thu, 12 Oct 2017 14:07:00 -0700 Message-ID: <5132.1507842420@segfault.tristatelogic.com> X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 21:07:03 -0000 In message <12891.128.135.52.6.1507831901.squirrel@cosmo.uchicago.edu>, "Valeri Galtsev" wrote: >> (*) Disable process debugging facilities for unprivledged users >> >> WTF?? If it's your process, why should I care what you do to it? >> Why would anyone want to *prevent* any user from debugging a program, >> ever? This makes no sense. > >Not necessarily. The process may be yours, but the code you run may be >proprietary, and if you are let debug that, you may potentially discover >something that vendor wants to hide from you. I know, it probably is built >without dtrace for production use, still... How likely is it that ALL of these conditions will ever apply? (*) The vendor thinks he can hide his (compiled) secrets simply by disallowing *run-time* tracing... ignoring the possibility of simple decompilation of the associated binary. (*) The vendor thinks... for some reason... that he will somehow obtain the willing participation (or at least the acquiescence) of -every- sysadmin running -every- system onto which the program in question will ever be installed, i.e. that 100% of such admins will choose to hobble their systems, in this particular way (disallowing unprivledged process tracing), for the benefit of the vendor, possibly at the expense of the local user base. (*) The vendor -does- obtain willing (co-conspiratorial) participation on the parts of one or more sysadmins in this silly security-thru- obscurity scheme. And remember, all of the above has to happen in the context of a FreeBSD system, where binary-only proprietary products... secret or otherwise... are both largely non-existant and also rather an anathema to free software generally, and to FreeBSD specifically. In short, while I thank you or your comment, I would still assert that disabling non-privledged users from tracing/debugging their own running processes seems unlikely to be a thing that any sane sysadmin would voluntarily choose to do. >> (*) Insert stack guard page ahead of growable segments >>... >I personally have mixed feeling about this. By all means, please elaborate. Under what scenarios, if any, would the use of stack guards -not- be an exceptionally desirable thing? (I've already conceeded that memory-limited embedded uses are a special case. But there are specialized distros for that.) >> (*) Disable Sendmail service >>... >I have mixed feelings here as well, even though I always replace sendmail >with postfix since forever. As do I, also since forever. >I frankly do not know why sendmail is there by default. We agree. >Old UNIX tradition (and yes, I did pass configuration of sendmail >in my sysadmin's exam, but I still prefer human readable configs of >postfix. Not to mention architecture with security in mind). Yes. I also was effectively forced to learn Sendmail's "chicken scratches" configuration language, back in the day, and I still have my first edition 1993 Bat Book sitting right here on my desk. But for the past many years its sole purpose has been to act as a paperweight, to keep certain otherwise skittish cables in their proper places, in which capacity its heft and ponderous weight have proven invaluable. Postfix is clearly the better choice, both for config readability and also for security. So there's that. But also, like I said, we could have some much better install-time "hardening" option, in particular options to run various standard daemons inside of jails. If there were such options, I wouldn't criticize those as much as the current set of "hardening" options, because even though it is clear that it would be better, security-wise, to run every daemon in a jail that can be run in a jail, I for one would generally opt not to do so, just because I don't think the additional complexity would buy me much, speaking only for myself. If I was a sysadmin at, say, either Sony or Sandia Labs or Equifax, then I would almost certainly take a different view. Regards, rfg