[CentOS] New glibc for CentOS-6 and CentOS-7 and CVE-2015-7547

[Michael H]

On 17/02/16 14:39, Johnny Hughes wrote:
> On 02/17/2016 08:10 AM, Michael H wrote:
>>> The easy answer is yes .. glibc requires so many things to be
>>> restarted, that is the best bet.  Or certainly the easiest.
>>> 
>>> Note: in CentOS 7, there is also a kernel update which is rated
>>> as Important .. so you should boot to that anyway: 
>>> https://lists.centos.org/pipermail/centos-announce/2016-February/021705.html
>>>
>>>
>>> 
Here is a good link to figure out what to restart if you don't want to
>>> reboot:
>>> 
>>> https://rwmj.wordpress.com/2014/07/10/which-services-need-restarting-after-an-upgrade/
>>>
>>>
>>> 
and there is this thread:
>>> http://markmail.org/message/dodinyrhwgey35mh
>>> 
>>> But generalyl, after a glibc update or a kernel update ..
>>> rebooting is easiest and it ensures everything is protected.
>> 
>> Wow, so, I updated my server (yum update -y) which applied a new
>> kernel and the new glibc among other things, After the update
>> completed it knocked my master postgresql database offline.
>> 
>> 
>> Feb 17 13:46:11 db1 systemd: Starting PostgreSQL database
>> server... Feb 17 13:46:11 db1 pg_ctl: LOG:  invalid value for
>> parameter "max_stack_depth": 16384 Feb 17 13:46:11 db1 pg_ctl:
>> DETAIL:  "max_stack_depth" must not exceed 7680kB. Feb 17
>> 13:46:11 db1 pg_ctl: HINT:  Increase the platform's stack depth 
>> limit via "ulimit -s" or local equivalent. Feb 17 13:46:11 db1
>> pg_ctl: FATAL:  configuration file 
>> "/var/lib/pgsql/data/postgresql.conf" contains errors Feb 17
>> 13:46:16 db1 pg_ctl: pg_ctl: could not start server Feb 17
>> 13:46:16 db1 pg_ctl: Examine the log output. Feb 17 13:46:16 db1
>> systemd: postgresql.service: control process exited, code=exited
>> status=1 Feb 17 13:46:16 db1 systemd: Failed to start PostgreSQL
>> database server. Feb 17 13:46:16 db1 systemd: Unit
>> postgresql.service entered failed state. Feb 17 13:46:16 db1
>> systemd: postgresql.service failed.
>> 
>> 
>> I have kernel parameters specified in /etc/sysctl.conf
>> 
>> vm.swappiness=0 vm.overcommit_memory=2 vm.overcommit_ratio=90 
>> kernel.shmmax=35433480192 kernel.shmall=8650752
>> 
>> After the update my postgresql service could not start because
>> these parameters had been reset, I promptly rebooted to server to
>> re-apply them.
>> 
>> Has something changed?!? after a reboot the service still
>> complained that my max_stack_depth was too high because kernel
>> shmmax and shmall were too low with the same error shown above.
>> 
>> [root at db1 ~]# ulimit -a core file size          (blocks, -c) 0 
>> data seg size           (kbytes, -d) unlimited scheduling
>> priority             (-e) 0 file size               (blocks, -f)
>> unlimited pending signals                 (-i) 514616 max locked
>> memory       (kbytes, -l) 64 max memory size         (kbytes, -m)
>> unlimited open files                      (-n) 1024 pipe size
>> (512 bytes, -p) 8 POSIX message queues     (bytes, -q) 819200 
>> real-time priority              (-r) 0 stack size
>> (kbytes, -s) 8192 cpu time               (seconds, -t) unlimited 
>> max user processes              (-u) 514616 virtual memory
>> (kbytes, -v) unlimited file locks                      (-x)
>> unlimited
>> 
>> confirms that my entries in /etc/sysctl.conf were ignored.
>> 
>> Why would these not work anymore?
>> 
>> Are the parameters specified elsewhere now?
>> 
>> any information would be very helpful!
>> 
>> Thanks
>> 
>> Michael (slightly more grey now)
> 
> Since you are talking about SystemD .. I assume c7.
> 
> In c7 .. there is a symlink to /etc/sysctl.d/99-sysctl.conf to 
> /etc/sysctl.conf
> 
> Have you verified your sysctl.conf actually contains those settings
> still.
Contents are still in tact.

> 
> Your best bet on CentOS-7 is to create a new file in
> /etc/sysctl.d/ called something like 99-postgres.conf and put youjr
> mods in there. That way it will never change.
> 
> Also .. verify all the files in /etc/sysctl.d/ and /etc/sysctl.conf
> are set to this label for selinux:
> 
> unconfined_u:object_r:etc_t:s0

# ll -dZ /etc/sysctl.d
drwxr-xr-x. root root system_u:object_r:etc_t:s0       /etc/sysctl.d

# ll -Z /etc/sysctl.conf
-rw-r--r--. root root system_u:object_r:system_conf_t:s0 /etc/sysctl.conf

I tried restorecon -Frv /etc/sysctl* to no avail.

Should I manually re-label these or is this an issue with the
selinux-policy package having the incorrect defaults?

> 
> See this for labeling: red.ht/1ooTpiI
> 
> But, /etc/sysctl.conf should still work in centos-7.

Thanks,

Michael