elenca le applicazioni in esecuzione collegate a una libreria compromessa

1

È abbastanza comune che si presentino aggiornamenti di sicurezza per varie librerie di sistema sui server amministrati (Linux, principalmente Debian e Ubuntu). Posso eseguire gli aggiornamenti abbastanza facilmente, ma questo spesso lascia le applicazioni in esecuzione ancora collegate alle vecchie versioni delle librerie e potenzialmente ancora vulnerabili.

C'è un modo per elencare le applicazioni in esecuzione che sono collegate a una libreria particolare (probabilmente prima di eseguire l'aggiornamento) o (molto meglio) per elencare le applicazioni che sono collegate ai file della libreria che non sono più collegati nel file system? (esegui dopo l'aggiornamento)

Sarebbe utile avere qualcosa che potrei eseguire prima degli aggiornamenti, ma questo non sembra adattarsi facilmente a un flusso di lavoro di manutenzione del sistema, e sarebbe facile non farlo in modo coerente. Sarebbe meglio, penso, controllare regolarmente la presenza di eseguibili collegati a librerie che non sono più presenti nel sistema. Forse può essere estratto da /proc in qualche modo?

[Per circa un miliardo di punti extra, fornisci una soluzione che trovi anche tali situazioni per i processi in esecuzione all'interno di contenitori, virtualenv, ecc.]

    
posta mc0e 30.01.2017 - 03:29
fonte

2 risposte

2

UPDATE: ecco uno script di Bash che penso faccia più di quello che stai chiedendo. Analizzerà i processi attualmente in esecuzione ed elencherà i pacchetti RPM che contengono librerie attualmente caricate in memoria per quei processi.

#!/bin/bash

procs=$(find /proc -maxdepth 1 -type d -name "[0-9]*" | sed 's@/proc/@@')

for proc in $procs[*]; do
  if [ ! -f /proc/$proc/cmdline ]; then
    continue
  fi

  cmd=$(cat /proc/$proc/cmdline | sed 's/[\s\n]+//g')

  if [ -z "$cmd" ]; then
    continue
  fi

  echo "**** Scanning pid ($proc): $cmd"
  echo

  echo "Dependent RPM Packages:"
  (
    libs=$(sudo lsof -p $proc -a -d mem 2>/dev/null | awk '{print $NF}' | grep "\.so")
    for lib in $libs; do
      echo $(rpm -qf $lib)
    done
  ) | sort -u
  echo
done

Potresti scrivere un semplice script Bash per capire quali binari sono dipendenti da una particolare libreria.

Per ottenere l'elenco dei binari sul disco interessato:

#!/bin/bash

dir=$1
lib=$2

for bin in $(find $dir -type f -executable); do
  ldd $bin | grep -q "$lib" && echo $bin
done

O nel caso di processi in esecuzione sul sistema potresti invece grep ps -ef e usare ldd allo stesso modo di sopra.

A seconda del tuo gusto di Linux potresti anche scoprire come un determinato aggiornamento del pacchetto influisce sul tuo sistema in base alle librerie contenute al suo interno.

Su un sistema CentOS è possibile eseguire quanto segue per ottenere l'elenco delle librerie condivise in un pacchetto:

$ rpm -ql zlib | grep "\.so"
/usr/lib64/libz.so.1
/usr/lib64/libz.so.1.2.7

Quindi potresti nuovamente utilizzare ldd sui file binari del sistema per determinare quali file binari utilizzano le librerie elencate.

    
risposta data 30.01.2017 - 04:07
fonte
0

La prima parte di una risposta sembra essere disponibile in /proc/$PID/map_files/ .

Sul mio portatile, guardando il processo in esecuzione di thunderbird, posso vedere voci come:

lr-------- 1 mc0e mc0e 64 Jan 30 15:51 7f8d54fe1000-7f8d55025000 -> /lib/x86_64-linux-gnu/libdbus-1.so.3.7.6 (deleted)

Riconosce che la versione collegata del file viene eliminata, anche se una versione aggiornata si trova nella stessa posizione.

C'è un po 'di script da fare qui, ma è piuttosto semplice nel caso di processi eseguiti direttamente sul file system host.

Sono ancora necessarie ulteriori indagini per capire come funzionerà per i processi in esecuzione in spazi dei nomi diversi.

    
risposta data 30.01.2017 - 05:58
fonte

Leggi altre domande sui tag