Newsgroup: it.comp.os.linux.sys
Titolo: Lanciare comandi da root via webserver ...

Hola,
supponiamo che io debba scrivere una web interface per mezzo della quale
è necessario lanciare comandi come root (su macchina Linux, tipicamente
Debian).
Per esempio, possiamo supporre che io usi un PC come router / firewall e
voglia scrivere una web interface (apache + php) per inserire le regole
tramite iptables (è solo un esempio, ma può andare) direttamente dalla
web interface.
Ora, di maniere per realizzare ciò me ne vengono in mente molte, a
partire da apache che gira come root (cosa che escludo a priori),
piuttosto che usare il suid bit sugli eseguibili che mi interessano,
piuttosto che usare suphp per alcune "parti" dell'interfaccia, piuttosto
che configurare sudo in maniera opportuna, ecc. ecc.
La domanda è: in linea di massima, qual è (se esiste) la "best practice"
per ottenere ciò che mi interessa ?
A naso configurerei sudo per permettere l'esecuzione di un set di
comandi come root da parte dell'utente con cui gira apache/php ... ma
magari si può fare di meglio. ;)
grazie mille.
ciao, f.

 per ottenere ciň che mi interessa ?
Una volta (l'unica) in cui ho avuto bisogno di una cosa simile ho fatto in modo
che PHP generasse file dati e/o file semafori e uno script cronnato ogni 5
minuti andava a vedere se c'erano i file e/o i semafori e si comportava di
conseguenza.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
E` stato presentato un francobollo commemorativo della prostituzione.
Costa 25 cent, ma se lo si lecca ne costa 50.
    --Chevy Chase

 comportava di conseguenza.
Intanto ti ringrazio ...
Ci avevo pensato anche io ed una volta avevo gi� implementato una cosa
pi� o meno del genere ... Per� poi bench� "di primo acchito" mi
sembrasse una separazione "sicura", avevo concluso che avere degli
script generati e "posseduti" dallo user di apache che venissero
lanciati ogni "tot" come root non fosse poi il massimo ... o meglio, a
root in qualche modo ci devi arrivare, per cui un "buco" lo crei per
forza da qualche parte ... � che il ritardo nell'esecuzione (e la
macchinosit� del sistema) non mi sembrava a posteriori giustificata dai
benefici.
Che ne pensi ?
Cercando di ridurre il "buco" allo stretto indispensabile, *forse* (e se
ne fossi certo non avrei postato la domanda ;) ) la soluzione migliore
sta nel configurare sudo per permettere ad apache di eseguire i comandi
strettamente necessari come root senza doversi ri-autenticare ...
Sarei curioso di sapere (ad esempio) come fanno prodotti come ipCop o
m0n0wall (vabb� questa � FreeBSD ma il concetto rimane) ...
grazie
ciao, f.

 lanciati ogni "tot" come root non fosse poi il massimo ... o meglio, a
Eh?
Gli script non sono posseduti dallo user di apache.
Apache si limita a scrivere una chiave da qualche parte che il tuo
script che gira in cron interpreta e si comporta come TU hai previsto
a fronte di quella chiave.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 a fronte di quella chiave.
Ok chiaro, il mio caso era un po' differente ed hai ragione.
Però vorrei eliminare il "delay" di esecuzione e l'uso di cron ...
Girerebbe una volta al minuto per sempre quando invece la configurazione
avverrebbe solo "ogni tanto" e dovresti *comunque* aspettare ...
M'e' venuto in mente che (usando sempre iptables come esempio) si
potrebbero scrivere dei wrapper in un linguaggio compilato che
limitassero le possibilità di mis-utilizzo di iptables ... poi potrei
usare sudo su quelli (e non su iptables in toto). Non so se ho voglia di
arrivare a tanto però. ;)
thanks
ciao, f.

 strettamente necessari come root senza doversi ri-autenticare ...
Io ho fatto proprio cosě.
Apache genera i file di config dei servizi in base alle richieste della 
web application.
Poi tramite sudo copia i file di config nelle posizioni giuste e riavvia 
i servizi coinvolti.

 Per� vorrei eliminare il "delay" di esecuzione e l'uso di cron ...
Il metodo pi� corretto in questi casi � quello di creare un demone che gira
come root e resta in ascolto per i comandi su uno unix socket su cui *solo*
l'utente apache pu� scrivere.
Per farti il demone in perl sono 25 righe di codice (Net::Server) e la parte
in PHP dovrebbe essere non molto dissimile in quanto a complessit�.
A questo punto lo script PHP scrive sulla socket i comandi da eseguire e
legge dalla socket le risposte; funziona senza problemi anche in una chroot
(basta che la socket sia creata l� dentro) funziona anche avendo pi� comandi
contemporaneamente se il backend lo prevede, e con 2 stupide modifiche puoi
anche sostituire la socket unix con una TCP e separare su diverse macchine
frontend e backend.
La cosa importante � di limitare in modo corretto e puntuale i comandi
eseguibili, quindi non lasciar passare *MAI* comandi di shell da eseguire ma
inventarsi un "protocollo" che preveda comandi prefissati e argomenti
vincolati, facendo una buona "sanitificazione" dell'input.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 magari si può fare di meglio. ;)
Il tuo naso ha buon fiuto, in quanto e` la soluzione piu` semplice, indolore 
e potenzialmente sicura :)
Enrico

 e potenzialmente sicura :)
;)
ciao, f.


Funziona ma ha 2 difetti:
a) i comandi da eseguire con sudo non devono essere comandi di sistema, ma
devono essere script che a loro volta richiamano comandi, in modo da fare
sanitizing dell'input ed evitare possibili, pericolosi abusi.
b) non funziona in chroot a meno di non includere nella gabbia tutti i
comandi, facendo perdere l'utilità della jail.
Su un server non esposto è comunque più che adeguato, su uno esposto dipende
da quel che c'è da eseguire :-)


 comandi, facendo perdere l'utilità della jail.
Vero.
Credo che la soluzione del demone (cui non avevo pensato) sia in
assoluto quella migliore.
ciao, f.

 l'utente apache pu� scrivere.
[..]
Ecco, questo � il tipo di risposta che speravo di ottenere ... ;) Non ci
avevo pensato ed in effetti - pur essendo un po' pi� complesso di
wrappers + sudo hai il vantaggio del chroot ...
non ho mai scritto un demone che ascolta su un socket ma con un pochino
di studio (e magari librerie) ce la dovrei fare ... do sicuramente
un'occhiata a Net::Server ;)
grazie
ciao, f.

Tutte cose interessanti e giuste, ma non c'e` nessun sistemista?
Nel senso qualcuno che voglia evitare di riscrivere le stesse cose
gia` scritte centinaia di volte con potenziali bachi nuovi, ma
preferisca usare e configurare un software gia` fatto all'uopo. Di
solito nel mondo open source, soprattutto per esigenze condivise e
diffuse, ce ne sono a bizzeffe. In questo caso specifico nessuno?

 solo l'utente apache può scrivere.
Senza offesa, ma non vedo perche` debba essere il metodo piu` corretto. In 
questo modo saresti costretto a gestire e mantenere due applicativi, con 
tutti i pro e i contro del caso (e.g. devi applicare un parsing all'input 
dell'utente). Utilizzando sudo, sei altamente sicuro di cio` che puoi fare, 
in quanto solamente gli applicativi configurati nel file sudoers possono 
essere eseguiti e come tutti gli applicativi *nix hanno un valore di ritorno 
ad indicare lo stato del processo. Una soluzione come quella da te proposta 
la vedrei bene quando l'interfaccia web e la macchina da pilotare siano 
differenti
Enrico

 ciao, f.
Io non darei i permessi ad apache...
Tempo fa avevo messo su un programmino in perl che stava in ascolto su 
una porta non accessibile dall'esterno, e php gli girava i comandi da 
eseguire.
Oddio, i motivi che mi hanno portato a questa tremenda scelta erano 
erano altri, ma a naso rifarei una cosa analoga....

 Net::Server è proprio quello, un demone già fatto da riutilizzare :-)
Veramente intendevo qualcosa di piu`, cioe` il programma gia` fatto,
ma effettivamente dipende dalle esigenze. Se si tratta di operazioni
standard, allora probabilmente e` possibile trovare qualcosa di gia`
fatto, diversamente se si tratta di esigenze particolari potrebbe
essere necesario farselo con Net::Server o chi per lui.
Andrea

 differenti
O se vuoi avere la massima sicurezza unitamente alla massima versatilità :-)


 
il problema lo hanno gia affrontato con
http://www.zeroshell.net/eng/UMTS-HSDPA-Mobile-Router/

Il 19/06/10 20:33, twistedbrain ha scritto:

Tutto dipende dalla portata dell'applicazione, per lavoretti in locale 
il Net::Server va più che bene, se la cosa si ingrossa e bisogna 
prevedere il porting su sistemi diversi conviene decisamente farsi un 
modulo per Webmin, questo da anche il vantaggio di poter gestire il 
singolo modulo attraverso apposito account, supporta SSL, è semplice da 
installare/configurare, multipiattaforma e consente di sfruttare delle 
API interne per richiamare funzioni da altri moduli ecc..

 per ottenere ciò che mi interessa ?
you are reinventing the wheel.
La best practice - IMHO - è scrivere un modulo per webmin ... ammesso
che non esista già un modulo che fa quel che tu cerchi.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

Il problema è anche il pregio, lanci i comandi da root.
per ovviare problemi puoi delimitare il campo di azione di PHP,puoi 
definire il campo di azione del WebServer, limitare le possibilità di 
root oppure nascondere root con alias.
E si uno delimita l'accesso a root e poi c'è PHP, un contrasto che fino 
ad oggi, che io sappia non ha portato disastri, ma l'inventiva non ha 
limiti.
Il WebServer è accessibile? con quali strumenti? fino a quale livello 
con ogni singolo strumento?
Se hai ben chiare le risposte a queste domande hai una buona protezione.
Non sò quale sia la Best practise in ambito di sicurezza, è arduo dire è 
questa, si può essere smentiti in qualsiasi momento.
di solito è l'insieme che dà i migliori risultati.

 che non esista gi� un modulo che fa quel che tu cerchi.
Ammetto (aaargh!) che non lo conoscevo ... l'ho installato ieri su una
macchina di test.
Non sembra affatto male, con calma me lo "spippolo" un po'. ;)
grazie !
ciao, f.

 comandi, facendo perdere l'utilità della jail.
Non saprei quanto sia necessaria, una chroot la vedo sensata nel momento in 
cui l'applicativo non deve comunicare con il sistema, cosa che non 
sembrerebbe riflettere questa situazione
Enrico

 sembrerebbe riflettere questa situazione
La chroot IMHO è totalmente inutile nel 99.9% dei casi, ma in ogni caso c'è
chi la usa soprattutto con i web server.


 una sql-injection. 
Diciamo anche che, se vogliamo essere polemici, un'applicazione del genere 
non la farei in PHP proprio perche` questo linguaggio non mette abbastanza 
paletti nella scrittura di codice non sicuro (ok, posso scrivere codice non 
sicuro anche in altri linguaggi, ma ho anche a disposizione dei mezzi che mi 
evitano eventuali problemi futuri)
Enrico

 macchina di test.
secondo me c'è già il modulo che fa quel che tu cerchi.


 modulo per Webmin, 
Ecco, giusto a quello pensavo. Per curiosità, su quale sistema si basa 
Webmin fra quelli di cui si discute in questo thread?
P

 Webmin fra quelli di cui si discute in questo thread?
Nessuno. E' un demone che gira come root con il proprio web server integrato
che gira (di default) sulla porta 10000. Di fatto è un sistema che non deve
essere pubblicato dato che appunto non gestisce la separazione dei privilegi
e che per questo in passato ha avuto non pochi problemi di sicurezza. Un bug
in webmin ti fa lavorare nel sistema come root.
Oltre a questo webmin ha un'architettura fatta con i piedi che mostra
chiaramente i limiti di una soluzione partita con un obbiettivo ed estesa
con pezze per soddisfare altre necessità che invece avrebbero avuto bisogno
di una completa reingegnerizzazione dell'applicazione.
Personalmente sconsiglio decisamente il suo utilizzo in produzione, tantopiù
su server esposti su Internet dove è opportuno che non sia nemmeno installato.


 c'e' Linux ma FreeBSD.
Hanno risolto sapendo scrivere codice in modo intelligente ed utilizzando i
vari code-checker disponibili. PHP è sicuro se uno sa programmare bene, ma
il problema è che è difficilissimo trovare programmatori PHP che sappiano
quel che fanno; la maggior parte di loro sono i c.d. web developer.


 nemmeno installato.
Sottoscrivo.
Enrico

 comando con quei parametri (che possono essere anche delle regexp)
Non sapevo che si potessero usare anche regexp e la cosa mitiga in parte il
problema; alla fine è sempre una validazione dell'input, ma almeno per
comandi semplici è "integrata". :-)
In ogni caso continua a sussistere per programmi un po' più complessi del
semplice rm o cat. Come fai a creare delle regexp significative e gestibili
per esempio per iptables? Concorderai che è molto più semplice creare un
wrapper e lasciare che sia uno script a decidere cosa è accettabile e cosa
no, magari usando anche regexp al suo interno.
