Re: Library security updates
If it doesn't protect us is there practicable way to make sure we are genuinely protected short of rebooting the whole system every time there is a security update? Depending on what the update is. If you want to be 100% certain, reboot. If you don't want to reboot, you can hunt through what programs use certain libraries using ld - however the effort taken to do this is much more than a reboot - and probably takes longer. It actually isn't that hard to track down. [root@colo-a2vm t2]# lsof -n | grep gcc hpiod 2649 root DEL REG 252,0 4718941 /lib64/libgcc_s-4.1.2-20080825.so.1;545bc2ea mysqld 2851mysql DEL REG 252,0 4718941 /lib64/libgcc_s-4.1.2-20080825.so.1;545bc2ea libvirtd 3121 root DEL REG 252,0 4718941 /lib64/libgcc_s-4.1.2-20080825.so.1;545bc2ea yum-updat 3343 root DEL REG 252,0 4718941 /lib64/libgcc_s-4.1.2-20080825.so.1;545bc2ea smartd 3469 root DEL REG 252,0 4718941 /lib64/libgcc_s-4.1.2-20080825.so.1;545bc2ea automount 6482 root DEL REG 252,0 4718600 /lib64/libgcc_s-4.1.2-20080825.so.1.#prelink#.dvRyeN httpd 11089 root mem REG 252,0 58400 4718834 /lib64/libgcc_s-4.1.2-20080825.so.1 php 11639 ioi mem REG 252,0 58400 4718834 /lib64/libgcc_s-4.1.2-20080825.so.1 php 24239 ioi mem REG 252,0 58400 4718834 /lib64/libgcc_s-4.1.2-20080825.so.1 httpd 27057 daemon mem REG 252,0 58400 4718834 /lib64/libgcc_s-4.1.2-20080825.so.1 httpd 27058 daemon mem REG 252,0 58400 4718834 /lib64/libgcc_s-4.1.2-20080825.so.1 You can tell the processes that were not restarted as they show DEL instead of mem...
Re: Library security updates
On 01/28/2015 10:48 AM, Steven Haigh wrote: And indeed, if yum updates a daemon due to security fixes does the daemon restart? By default, package updates won't restart running programs. This is a manual step. glibc is special. When glibc is updated it executes from %post /usr/sbin/glibc_post_upgrade.x86_64 which severely lacks documentation, best I could find is it runs telinit u; service sshd condrestart It definitely does restart crond I'm sure since a few years back it wend bad and crond failed across the whole plant. Not sure I actually trust the above to actually restart everything.
Re: Library security updates
On 28/01/2015 8:35 PM, John Rowe wrote: I'm sure many people will have seen the recent security update on gethostbyname(), etc. Apparently exim can be vulnerable to this. Yes it is. This raises the question: does updating a library package actually protect systems from the vulnerability or do daemons continue to use the (insecure) version of the library call they linked at start up? The program (exim in this case) uses a function in the library. It will continue to use the library that was present when the program started until you restart the program. And indeed, if yum updates a daemon due to security fixes does the daemon restart? By default, package updates won't restart running programs. This is a manual step. If it doesn't protect us is there practicable way to make sure we are genuinely protected short of rebooting the whole system every time there is a security update? Depending on what the update is. If you want to be 100% certain, reboot. If you don't want to reboot, you can hunt through what programs use certain libraries using ld - however the effort taken to do this is much more than a reboot - and probably takes longer. -- Steven Haigh Email: net...@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 signature.asc Description: OpenPGP digital signature
Library security updates
I'm sure many people will have seen the recent security update on gethostbyname(), etc. Apparently exim can be vulnerable to this. This raises the question: does updating a library package actually protect systems from the vulnerability or do daemons continue to use the (insecure) version of the library call they linked at start up? And indeed, if yum updates a daemon due to security fixes does the daemon restart? If it doesn't protect us is there practicable way to make sure we are genuinely protected short of rebooting the whole system every time there is a security update? John
Re: Library security updates
On 28/01/15 10:35, John Rowe wrote: And indeed, if yum updates a daemon due to security fixes does the daemon restart? Yes and no. It mostly depends on what kind of package has been updated. Some packages triggers restart of daemons, some does not. Generally speaking, packages such as httpd, postfix, openssh-server and such usually restarts the service when the package is updated. But for library packages it may be mixed. Some times daemons are restarted, but it usually depends on helper scripts (which glibc does have). But having that said, it doesn't mean all daemons are restarted. If it doesn't protect us is there practicable way to make sure we are genuinely protected short of rebooting the whole system every time there is a security update? I generally treat core system libraries (such as glibc) on the same line as kernel updates. So I try to do a reboot as soon as possible. Depending on the severity of the system library update and the time until I can schedule a reboot defines if I do a restart of critical daemons. Generally I only restart daemons using the network, but I have very few boxes where users log into with shell access. All non-restarted processes will use the old library until it is restarted. This is why a reboot is helpful when core system libraries are updated, it reassures you that all processes use the latest code. And having a reboot every now and then is also good sys-admin practice, to ensure the setup/configuration is always persistent - for the times if an abrupt reboot happens. -- kind regards, David Sommerseth
Re: Library security updates
Actually, looking at what files were updated, that should probably be lsof -n | grep -e libc- (Probably not a lot of difference in the programs listed, but...) - Original Message - From: John Lauro john.la...@covenanteyes.com To: Steven Haigh net...@crc.id.au Cc: scientific-linux-users@fnal.gov Sent: Wednesday, January 28, 2015 9:13:08 AM Subject: Re: Library security updates If it doesn't protect us is there practicable way to make sure we are genuinely protected short of rebooting the whole system every time there is a security update? Depending on what the update is. If you want to be 100% certain, reboot. If you don't want to reboot, you can hunt through what programs use certain libraries using ld - however the effort taken to do this is much more than a reboot - and probably takes longer. It actually isn't that hard to track down. [root@colo-a2vm t2]# lsof -n | grep gcc hpiod 2649 root DEL REG 252,0 4718941 /lib64/libgcc_s-4.1.2-20080825.so.1;545bc2ea mysqld 2851mysql DEL REG 252,0 4718941 /lib64/libgcc_s-4.1.2-20080825.so.1;545bc2ea libvirtd 3121 root DEL REG 252,0 4718941 /lib64/libgcc_s-4.1.2-20080825.so.1;545bc2ea yum-updat 3343 root DEL REG 252,0 4718941 /lib64/libgcc_s-4.1.2-20080825.so.1;545bc2ea smartd 3469 root DEL REG 252,0 4718941 /lib64/libgcc_s-4.1.2-20080825.so.1;545bc2ea automount 6482 root DEL REG 252,0 4718600 /lib64/libgcc_s-4.1.2-20080825.so.1.#prelink#.dvRyeN httpd 11089 root mem REG 252,0 584004718834 /lib64/libgcc_s-4.1.2-20080825.so.1 php 11639 ioi mem REG 252,0 584004718834 /lib64/libgcc_s-4.1.2-20080825.so.1 php 24239 ioi mem REG 252,0 584004718834 /lib64/libgcc_s-4.1.2-20080825.so.1 httpd 27057 daemon mem REG 252,0 584004718834 /lib64/libgcc_s-4.1.2-20080825.so.1 httpd 27058 daemon mem REG 252,0 584004718834 /lib64/libgcc_s-4.1.2-20080825.so.1 You can tell the processes that were not restarted as they show DEL instead of mem...
