Date: Thu, 12 Oct 2017 16:50:50 -0500 (CDT) From: "Valeri Galtsev" <galtsev@kicp.uchicago.edu> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-questions@freebsd.org Subject: Re: Install-time "hardening" options Message-ID: <12473.128.135.52.6.1507845050.squirrel@cosmo.uchicago.edu> In-Reply-To: <5132.1507842420@segfault.tristatelogic.com> References: <5132.1507842420@segfault.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, October 12, 2017 4:07 pm, Ronald F. Guilmette wrote: > > In message <12891.128.135.52.6.1507831901.squirrel@cosmo.uchicago.edu>, > "Valeri Galtsev" <galtsev@kicp.uchicago.edu> 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. I probably gave not the best example, and even though it is hard to disagree with your argument, I still have my opinion without change. I probably should mention that I wasn't always UNIX person, and while running Linux boxes (and definitely not using FreeBSD jail on these ;-) I had to run mail, web, server, and had regular user logins on some of these boxes. And as I was running these in assumption that bad guys are already inside, I had quite a few thing made not feasible for my users. One of which: they were not able to run anything of their own, (all places users can write were mounted noexec, nosuid, nosgid, nodev). Now you know where I'm coming from, hence my attitude about debugging, at least on some machines. > >>> (*) 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.) Well, I actually have a mixed feelings about stack guards themselves, I do not feel they give good protection for other memory areas, be those areas just few addresses away or far-far away. But that must be just my ignorance, and you, as system architecture expert, are quite likely right, no matter what I feel like. > >>> (*) 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. Hm, I have mixed feelings here as well. All of us use jails, and we do as elaborate setup for each particular box as we feel necessary. And we use different ways of creating and maintaining jails. Say, some like ezjail, I set up jails "by the book" - which fools me into thinking that what I made is more transparent for me. I would rather have default installation produce plain, simple, and straightforward system (easy to master, administer, and further configure and expand for newcomers, - and I consider myself "newcomer" often as well, so you can safely ignore what person who most likely is ignorant - I - says ;-) Thanks for all your insights you have shared! Valeri > > 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 > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12473.128.135.52.6.1507845050.squirrel>