Install-time "hardening" options

Ronald F. Guilmette rfg at
Thu Oct 12 17:50:11 UTC 2017

OK, I admit that I'm way behind the times, but yesterday was the first
time I ever saw all of these new "harding" options an install time,
i.e. the ones shown in the second screenshot here:

Anyway, I've got to say that I'm perplexed by most or all of these, *not*
because I don't understand at least something about what each one is
all about, but rather, I'm perplexed because I'm not even sure why
most or all of these are even options.  Maybe somebody can & will

I look at each one of these "hardening" options and I think that there
is only one current and obvious answer, i.e. it should -always- be
disabled, for all installations, or else it should always be enabled
for all installations.  Let's go through them one by one...

(*) Hide processes running as other users

    Well, I mean, yea.  Obviously.  If you ain't root, then processes
    belonging to other users are none of your damn business.  So, um,
    why is this even optional?

(*) Hide processes running as other groups

    This one is a bit tricker, and I don't know the Right Answer.

(*) Disable reading kernel message buffers for unprivledged users

    Why would anyone NOT want this altogether sensible restriction imposed?

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

(*)  Randomize the PID of newly created processes

     Really?  Are there are known exploits which rely on the predictability
     of spawned PIDs??  Name three.  Otherwise, this option is just silly.

(*) Insert stack guard page ahead of growable segments

    The only case where I could see this NOT being a good idea would be
    in some limited embedded contexts where main memory is really scarce.
    But unless I'm wrong, that *ain't* what the general releases of FreeBSD
    are targeting.  (There are specialized fBSD distros for that.)  So again,
    why is this even optional?  It makes no sense.

(*)  Clean the /tmp filesystem on system startup

     Really?  Are there are known exploits which rely on the crap leftovers
     in /tmp between reboots and which are NOT completely thwarted by simply
     setting file permissions and ownership properly?

(*)  Disable opening Syslogd network socket (disables remote logging)

     Unbelievable!  This was a a well-known and well-documented security
     hole / exploit twenty years ago already!  And it had -been- a well-
     known and well-documented security hole for about a decade already
     when, about 15 years ago, I personally made one whole hell of a lot
     of sysadmins all over the Internet hopping mad when I started writing
     console log message to them, each and every time one of their dumb ass
     end-luser spammers spammed me.

     I can't believe that the -default- on FreeBSD is apparently to leave
     the Syslog open to trivial UDP invasion by every Tom, Dick, and Harry
     on the whole bloody Internet.  Sheer madness!

(*)  Disable Sendmail service

     This seems like a rather bizzare "hardening" option.  What I mean is
     that for the sake of people who are ernestly concerned about security,
     I can think of a whole host of other "secure" alternatives, other than
     just simply not running Sendmail.  The first one that comes to mind is
     running Postfix instead.  And also, of course, where is the option
     to run Sendmail, or Postfix, or any of the numerous other common
     daemons within isolated jails?

     Forgive me, but it just seems rather stingy to only offer the security-
     conscious sysadmin -only- the option to not run Sendmail (but I guess
     that's better than nothing).

Just my two cents... worth what you paid for them.

More information about the freebsd-questions mailing list