Install-time "hardening" options

[Ronald F. Guilmette]

In message <12891.128.135.52.6.1507831901.squirrel at cosmo.uchicago.edu>, 
"Valeri Galtsev" <galtsev at kicp.uchicago.edu> 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.

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

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

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