Install-time "hardening" options

[Trond Endrestøl]

On Thu, 12 Oct 2017 10:50-0700, Ronald F. Guilmette wrote:

> 
> 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:
> 
>     https://forums.freebsd.org/threads/57807/
> 
> 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
> explain.
> 
> 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?

Maybe it's a system for your own personal use, not some system for the 
many.

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

When building ports a lot of crap ends up in /tmp only to be removed 
manually. Why not automate this to some extent?

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

Anyone in their right mind would employ some sort of (centralised) 
packet filtering, usually on their router or core switch. This would 
include blocking any outside access to UDP port 514.

Once your network grows beyond a few FreeBSD hosts, it makes sense to 
have a central syslog host. Such a thing helped me determine hardware 
failure and not sabotage as the cause when one of our web servers died 
a couple of years ago. The last messages from the web server was about 
a USB device disappearing and reappearing. I also checked the logs of 
the security system to verify no illegal access to our server room.

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

This largely depends on your needs. I have all local email forwarded 
to the root account on a central host, and I don't mind running 
sendmail for that purpose, or whatever FreeBSD ships with. This makes 
it easier to review all runs of periodic(8) across all my systems.

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

-- 
Trond.