Install-time "hardening" options

Valeri Galtsev galtsev at
Thu Oct 12 21:50:52 UTC 2017

On Thu, October 12, 2017 4:07 pm, Ronald F. Guilmette wrote:
> In message <12891. at>,
> "Valeri Galtsev" <galtsev at> 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

>>> (*) 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!


> 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 at mailing list
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at"

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

More information about the freebsd-questions mailing list