Install-time "hardening" options

[Valeri Galtsev]

On Thu, October 12, 2017 12:50 pm, 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 agree in general, but disagree or rather have comments on some points

>
> 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.

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... Wherever I don't comment I
100% agree.

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

I personally have mixed feeling about this.

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

I have mixed feelings here as well, even though I always replace sendmail
with postfix since forever. I frankly do not know why sendmail is there by
default. 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).

Thanks for sharing!

Valeri

>
> Just my two cents... worth what you paid for them.
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at freebsd.org"
>


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