Archivi tag: Linux

tux-jail-banner

Rompere una jailroot

A volte capita che su appliance o semplicemente su sistemi con sicurezza molto elevata il nostro utente sia collocato in una jailroot, ossia in un ambiente isolato dal root filesystem e con un ristretto numero di comandi disponibili.

Ovviamente stiamo parlando di una situazione in ambiente Linux (ovvero un qualsiasi sistema basato su un kernel linux, ed in particolare superiore o equivalente alla version 2.4).

Ebbene non essendo possibile mantenere questo isolamento  (per varie ragioni, ma essenzialmente per la necessaria gestione dei processi) per quanto riguarda il filesystem virtuale /proc, questo ci consente di rompere parzialmente l’isolamento della jailroot e conoscere molto del sistema reale che l’isolamento presunto ci voleva nascondere.

Essenzialmente la rimozione di molti comandi amministrativi (e molte utilità) vorrebbero impedire la lettura di quelle configurazioni che di norma potrebbero essere lette (ma non manipolate) da un utente normale; altre configurazioni non sono accessibili per la sicurezza intrinseca del filesystem. Ma stiamo parlando delle configurazioni statiche. La configurazione in essere (running) risiede (per molte componenti del sistema essenzialmente) nel kernel, ed il kernel è accessibile tramite il filesystem virtuale /proc, in moltissime sue parti anche da utenti non privilegiati.

Mediante questo assunto possiamo portare quindi due esempi su come accedere a informazioni quali tabella di routing (in assenza del comando route) oppure alla lista dei processi (in assenza del comando ps) facendo uso solo del filesystem virtuale /proc e di soli comandi interni ad una bash.

Tabella di routing

Se non ci hanno voluto fornire il comando route, possiamo ovviare mediante:

while read IFA DST GW FL REF USE MET MSK MTU WIN IRTT do
if [ $IFA != "Iface" ]; then
echo -ne "$IFA\t ${DST:4:2}${DST:6:2}${DST:2:2}${DST:0:2}"
echo -e "\t${GW:4:2}${GW:6:2}${GW:2:2}${GW:0:2}"
fi
done < /proc/net/route

Unico neo di questo approccio è il non poter contare su un comando tipo ipcalc per tradurre da formato esadecimale a dotted-quad. Però questo può essere fatto in un secondo momento: quello che conta è che il dato è perfettamente accessibile.

Lista processi

Se non ci hanno voluto fornire il comando ps,  possiamo ovviare con:

 for pid in /proc/[0-9]* do
[ -f $pid/cmdline ] && read CMD < $pid/cmdline while read TAG VALUE REST; do
[ "$TAG" = "Pid:" ] && echo -ne $VALUE"\t"
[ "$TAG" = "PPid:" ] && echo -ne $VALUE"\t"
[ "$TAG" = "Name:" ] && echo -ne $VALUE"\t"
[ "$TAG" = "State:" ] && echo -ne $VALUE $REST"\t"
[ "$TAG" = "Uid:" ] && echo -ne $VALUE"\t"
done < $pid/status
[ -n "$CMD" ] && echo -n $CMD
echo done

Potremmo continuare a ricercare e decodificare informazioni da /proc.

Ma è sufficiente per indicare il senso di questo approccio.

tux+ibm

Linux e appliances

Mi è recentemente capitato di configurare degli switch FC IBM, modello 2498_24.
Nel verificare alcuni parametri di versione per la configurazione che mi accingevo a fare mi è andato l’occhio su un numero alquanto sospetto:

SAN:root> version
Kernel:     2.6.14.2
Fabric OS:  v6.4.2a
Made on:    Mon Jul 18 22:27:42 2011
Flash:        Tue Jan 3 17:18:42 2012
BootProm:   1.0.9

2.6.14 … interessante, mi dico. E mentre la parola Linux mi sovviene alla mente, mi ritornano certe polemiche mosse da certi “guru” sulla presunta pericolosità di adottare sistemi Linux nei comparti del networking e della sicurezza, ed è più sicuro affidarsi ad appliance da migliaia di euro (senza considerare licenze d’uso, upgrade, assistenze, ecc).
Ed eccomene una sotto mano, di queste appliance, e per di più costruita da “mamma IBM”, e chi ti trovo? Un bel sistema Linux con kernel 2.6: certo, customizzato, certo con tantissimi comandi ad hoc (vedi cosiddetto FOS) per il ruolo di questo dispositivo. Ma in finale sempre un kernel Linux.

Pertanto rido di quanti credano che comprare è meglio che realizzare in economia a partire da un semplice Linux box, specialmente per quei servizi che sono già completi e “di serie” quali un netfilter o altri elementi di livello kernel. Il resto sono pezzi di ferro da aggiungere tutto intorno.

Tanto per la cronaca; ecco altre dimostrazioni che un IBM 2498_24 è a tutti gli effetti un Linux box, customizzato e ridotto al minimo necessario.

SAN:root> uname -r
2.6.14.2
SAN:root> uname -a
Linux SAN 2.6.14.2 #1 Sat Jul 16 10:19:20 PDT 2011 ppc unknown
SAN:root> ls -l /
total 96
drwxr-xr-x   2 root     sys          4096 Jan  3  2012 bin/
drwxr-xr-x   2 root     sys          4096 Jan  3  2012 boot/
drwxr-xr-x   2 root     root         4096 Jan  3  2012 config/
drwxrwxrwx  41 root     sys          4096 Jan  3  2012 core_files/
drwxr-xr-x   3 root     sys          4096 Nov 13 12:28 dev/
lrwxrwxrwx   1 root     root           10 Nov 13 12:28 diag -> /proc/diag/
drwxr-xr-x  17 root     sys          4096 Jan 21 13:02 etc/
drwxr-xr-x   2 root     sys          4096 Jul 18  2011 export/
drwxr-xr-x  18 root     sys          4096 Nov 13 12:28 fabos/
drwxr-xr-x   2 root     sys          4096 Jul 18  2011 import/
drwxr-xr-x   2 root     sys          4096 Jul 18  2011 initrd/
drwxr-xr-x   6 root     sys          4096 Jan  3  2012 lib/
lrwxrwxrwx   1 root     sys            11 Jan  3  2012 libexec -> usr/libexec/
drwx------   2 root     root        16384 Jan  3  2012 lost+found/
drwxr-xr-x  24 root     root         4096 Jan  3  2012 mnt/
dr-xr-xr-x 214 root     root            0 Jan  1  1970 proc/
drwxr-x---   4 root     sys          4096 Jan  3  2012 root/
drwxr-xr-x   2 root     sys          4096 Jan  3  2012 sbin/
lrwxrwxrwx   1 root     sys             9 Jan  3  2012 share -> usr/share/
drwxr-xr-x   2 root     root         4096 Jan  3  2012 standby_sbin/
drwxrwxrwx   3 root     sys          4096 Jan  3  2012 support_files/
drwxr-xr-x   2 root     sys          4096 Jul 18  2011 tftpboot/
drwxrwxrwt   5 root     root            0 Jan 23 14:26 tmp/
drwxr-xr-x   2 root     sys          4096 Jul 18  2011 users/
drwxr-xr-x  11 root     sys          4096 Jan  3  2012 usr/
drwxr-xr-x  11 root     sys          4096 Jan  3  2012 var/

E vogliamo parlare di un

tail /var/log/nslog.txt
?

Va bene. Ogni altra considerazione è puramente superflua.

Il seguente articolo è anche disponibile nel seguente Blog

tux-banner

Linux & SAN

Premesso che lasceremo al lettore l’onere di trovare il software citato nel post nel sistema di pacchetti della distribuzione su cui opererà, diamo alcuni suggerimenti utili per la configurazione di connessioni a SAN per sistemi Linux.

Esistono molti modi per determinare le informazioni su indirizzi dell’HBA e mappature dei dischi, e in giro si trovano molti tutorial al riguardo.

Il punto finale può essere sempre considerato il seguente comando:

sg_map -x

che ci fornisce i nomi dei dispositivi a blocchi mappati su una qualche LUN.

Partiamo da qui per determinare altra informazione, in genere molto utile in sistemi complessi per orientarsi tra i vari dischi e storage: il nome dello storage e le WWN delle LUN.Ipotizziamo che la nuova LUN sia stata mappata sul dispositivo /dev/sda, quindi interroghiamo questo per determinare le informazioni richieste:

  • Informazioni sullo storage (produttorel,modello,S/N)
/lib/udev/scsi_id --page=0x80 --whitelisted \
--device=<b>/dev/sda</b> | awk '{ print substr($0,2)}'
  • Informazioni sulla LUN (WWN)
/lib/udev/scsi_id --page=0x83 --whitelisted \
--device=<b>/dev/sda</b> | awk '{ print substr($0,2)}'

Consigliamo di trascrivere queste due linee di codice in due distinti file, denominati scsi_storage_info e scsi_lun, dotarli di diritti di esecuzione e porli nel percorso /sbin (tutto quanto detto in questo post presuppone che siate amministratori delle macchine su cui operate). Avrete così altri comandi utili nel processo di configurazione di una connessione a SAN in un host Linux.