CentOS - Aug 2019 - another bizarre thing...

On Tue, Aug 06, 2019 at 03:18:06PM -0600, Warren Young
wrote:
> On Aug 6, 2019, at 7:59 AM, Fred Smith <fredex at
fcshome.stoneham.ma.us> wrote:
> > 
> > On Tue, Aug 06, 2019 at 05:27:54AM -0600, Warren Young wrote:
> >> On Aug 5, 2019, at 6:57 PM, Fred Smith <fredex at
fcshome.stoneham.ma.us> wrote:
> >>> 
> >>> no core file (yes, ulimit is configured)
> > 
> > yeah, I meant "ulimit -c unlimited" is in effect.
> 
> That only affects the shell it?s set for, which isn?t generally important
for a service, since we no longer start services via shell scripts in the
systemd world.
> 
> > I had no idea systemd had made such a drastic change.
> 
> This isn?t a systemd change, it?s a *system* change.  The only reason
systemd is involved is that it also has its own defaults, just as your shell
does, overridden by the ulimit command.  Steps 1-3 remove the system limits,
then 4 & 5 remove the systemd limits under that, which can affect your
service, if it?s being started via systemd.
> 
> > or is it that
> > someone at RH decided to make it (nearly) impossible to do? I fail
> > to see how it is beneficial to anyone to make it so hard to get
> > core dump files.
> 
> Core dumps are a security risk.  They?re memory images of running
processes.  If you configure your server like I give in my recipe, every process
that drops core will create a world-readable file in /tmp showing that process?s
memory state, which means you can recover everything it was doing at the time of
the crash.
> 
> So, if you can find a way to make, say, PAM or sshd drop core, you?ll get
live login details in debuggable form, available to anyone who can log into that
box.
> 
> You definitely want core dumps off by default.
> 
> Making core dumps enabled by default is about as sensible as enabling rsh
by default.
Oh of course. duh!

What we've alwayws done with this program is to put "ulimit -c
unlimited"
in the script that sets its environment then starts the program itself.
that minimizes the attack surface.

Setting up as you described earlier, is there a way to allow only
a single program to drop core?


-- 
---- Fred Smith -- fredex at fcshome.stoneham.ma.us
-----------------------------
  "For him who is able to keep you from falling and to present you before
his
 glorious presence without fault and with great joy--to the only God our Savior
 be glory, majesty, power and authority, through Jesus Christ our Lord, before
                     all ages, now and forevermore! Amen."
----------------------------- Jude 1:24,25 (niv) -----------------------------

On Aug 6, 2019, at 8:48 PM, Fred Smith <fredex at fcshome.stoneham.ma.us>
wrote:
> 
> Setting up as you described earlier, is there a way to allow only
> a single program to drop core?
Of course.

The * in the limits.d file is a ?domain? value you can adjust to suit:

   
https://www.thegeekdiary.com/understanding-etc-security-limits-conf-file-to-set-ulimit/

You?d have to read the systemd docs to figure out the defaults for LimitCore,
but I suspect you don?t get cores until you set this on a per-service basis.

You can also adjust the sysctl pattern path to put cores somewhere secure. 
That?s the normal use of absolute paths: put the cores into a dropbox directory
that only root can read but anyone can write to.

Also, I should point out that my first step, removing ABRT, is a heavy-handed
method. Maybe what you *actually* want to do is learn to cooperate with ABRT
rather than rip it out entirely.

On Tue, Aug 06, 2019 at 09:02:37PM -0600, Warren Young
wrote:
> On Aug 6, 2019, at 8:48 PM, Fred Smith <fredex at
fcshome.stoneham.ma.us> wrote:
> > 
> > Setting up as you described earlier, is there a way to allow only
> > a single program to drop core?
> 
> Of course.
> 
> The * in the limits.d file is a ?domain? value you can adjust to suit:
> 
>    
https://www.thegeekdiary.com/understanding-etc-security-limits-conf-file-to-set-ulimit/
> 
> You?d have to read the systemd docs to figure out the defaults for
LimitCore, but I suspect you don?t get cores until you set this on a per-service
basis.
> 
> You can also adjust the sysctl pattern path to put cores somewhere secure. 
That?s the normal use of absolute paths: put the cores into a dropbox directory
that only root can read but anyone can write to.
> 
> Also, I should point out that my first step, removing ABRT, is a
heavy-handed method. Maybe what you *actually* want to do is learn to cooperate
with ABRT rather than rip it out entirely.
how about "simply" disabling and stopping it?


-- 
---- Fred Smith -- fredex at fcshome.stoneham.ma.us
-----------------------------
                      The eyes of the Lord are everywhere, 
                    keeping watch on the wicked and the good.
----------------------------- Proverbs 15:3 (niv) -----------------------------