Date: Thu, 12 Oct 2017 10:50:09 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-questions@freebsd.org Subject: Install-time "hardening" options Message-ID: <4436.1507830609@segfault.tristatelogic.com>
next in thread | raw e-mail | index | archive | help
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?
(*) 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4436.1507830609>