Newsgroup: it.comp.os.linux.sys
Titolo: Proteggere script bash

Ciao a tutti!
Esiste un qualche tool, come ad esempio zen guard per i file php, che � in 
grado di offuscare/criptare dei semplici script di bash?
Grazie!
Francesco 

 grado di offuscare/criptare dei semplici script di bash?
basta un banalissimo wrapper in C, sono 4 righe di codice, non � che ci
voglia chiss� che tool.
-- 
Massimo Bacilieri AKA Crononauta

 grado di offuscare/criptare dei semplici script di bash?
Uno free e' questo:
http://www.datsi.fi.upm.es/~frosal/sources/shc.html
Ma leggi qui prima: 
http://aplawrence.com/Linux/shc.html

 voglia chiss� che tool.
Io non conosco nulla di C se non che � la terza lettera dell'alfabeto
(che battuta del cappero), mi sai dire come fare questo wrapper in C?
Ed in che modo ti pu� proteggere dal codice? Incorporeresti lo script
in uno fatto in C?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 in uno fatto in C?
Esatto: il C è un linguaggio compilato e quindi distribuisci solo
l'eseguibile

 (che battuta del cappero), mi sai dire come fare questo wrapper in C?
OT
ma sei l'ex Peregrino?
-- 
Vide


non ho ben capito le altre risposte, comunque c'e' un comando che, se 
gli passi in input uno script bash, lui in output ti da un sorgente c o 
direttamente un eseguibile... nasce apposta con l'intento che dici tu.
ne parla ABS
http://tldp.org/LDP/abs/html/securityissues.html
il software che lo fa si chiama shc (shell compiler) pero' non lo trovo 
nei repository di debian... comunque c'e' il link, te lo scarichi e te 
lo compili... saranno 20k
-- 
Il Paradiso sono gli altri - Ertras

 Ma leggi qui prima: 
http://aplawrence.com/Linux/shc.html
Un lucchetto impedisce alla gente onesta di entrare a casa tua
ma non impedisce ai ladri di svuotarti l'appartamento.

 ma sei l'ex Peregrino?
ROTFL,
si. ;)
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 si. ;)
Puoi smetterla coi morph? :P
Non per altro, però alle volte ricerco vecchie discussioni su google groups 
perchè mi ricordo che qualcuno aveva chiesto qualcosa che adesso mi 
interessa, e tener traccia di tutti i tuoi nick tolkeniani sta cominciando 
ad essere complicato :P
-- 
Vide

 ma non impedisce ai ladri di svuotarti l'appartamento.
Sì però ci possono essere casi (come dice anche l'articolo) in cui può 
essere utile. Voglio dire, nessuno può recriminare se la gente fa un "cat 
script.sh", ma internamente si che si può dire qualcosa a qualcuno se 
decifra un qualcosa offuscato.
(che poi dentro l'offuscato non ci debba essere niente di sensibile siamo 
d'accordo)
-- 
Vide

 ad essere complicato :P
Be, non puoi ricercare per *tolkien* ? :-P


Facebook: Massimo Bacilieri

 rischio buffer overrun, quindi occhio) e hai già risolto.
Veramente penso che il suo obiettivo fosse non dare accesso al sorgente
dello script... 

 
Ma scusa, cosï¿œ hai il wrapper compilato, ma lo script
tuoscript.sh sarï¿œ sempre visibile, non viene inglobato
dentro il programma in C e poi compilato.


Pur non essendo molto chiaro cosa tu voglia fare (forse
era meglio spiegare il problema, piuttosto che la soluzione),
magari "tuoscript.sh" e` dell'utente "pippo" e leggibile solo
da lui, mentre il programma C e` suid "pippo".
Potrebbe anche funzionare...
bye,
-- 
piergiorgio

Gandalf Corvotempesta ha scritto:

rendi lo script accessibile anche in lettura ed esecuzione
solo a root e rendi suid il miniprogrammino C che sara` quindi
in grado di leggerlo, non pero` l'utente che lo lancia.
Io poi ho pochi, scarsi e frammentari C ricordi, ma l'include
di uno stdio.h in cima ce lo metterei.
Andrea

 solo a root e rendi suid il miniprogrammino C che sara` quindi
Eviterei root, se lo script ha un qualche buco di
sicurezza, l'utente magari non lo legge, ma puo`
riuscire ad eseguire altro con privilegi elevati.
bye,
-- 
piergiorgio

 Potrebbe anche funzionare...
Questa e` piu` precisa della mia e anche postata 3 minuti prima, solo 
che a me non compariva ancora quando ho spedito, costandoci 2 messaggi 
inutili (i miei, compreso questo).


No: tuoscript.sh lo puoi mettere in un percorso *fuori* dall'area web,
perciï¿œ sarï¿œ invisibile a chi arriva da http/https. Chi arriva da web
vedrï¿œ solo il wrapper.


 vedrà solo il wrapper.
Se viene acceduto da web e il cgi e' configurato correttamente, il sorgente
non si vede comunque. Ma dove hai letto che sara' usato da web? 

 inutili (i miei, compreso questo).
Figurati, e` un sollievo vedere che l'idea non era
proprio balzana... :-)
Con questo facciamo tre (inutili...).
bye,
-- 
piergiorgio

 Potrebbe anche funzionare...
Allora, spendo due parole in piï¿œ, perchï¿œ il problema mi pare chiaro,
visto che l'ho giï¿œ dovuto affrontare in passato, e quanto racconto ï¿œ nï¿œ
piï¿œ nï¿œ meno la soluzione che avevo trovato e che funzionava ottimamente.
L'obiettivo ï¿œ quello di fare in modo che da web uno possa ricevere in
output (o eseguire) uno script bash, che possa agire sul sistema e
restituire l'output non a una console ma a un browser client che accede
via http o https.
Si abbia quindi l'area http sotto /home/http, e qui ci sia la cartella
/home/http/cgi-bin nella quale vogliamo mettere uno script bash
"salcazzo.sh" che sia tipo:
#!/bin/bash
echo -e "Content-Type: text/html\n"
echo "<html><body><h1>SALCAZZO</h1></body></html>"
Questo script sia eseguibile.
Ora facendo cosï¿œ la cosa funziona, se uno mette come URL pubblico
http://tuositosalcazzo.fncl/cgi-bin/salcazzo.sh
lo script verrï¿œ eseguito.
Tuttavia in questo modo lo script ï¿œ accessibile direttamente, e uno
potrebbe scaricarlo e leggerlo, cosa che abbiamo detto voler impedire.
Allora lo script lo si mette in /usr/local/bin/salcazzo.sh, che ï¿œ
assolutamente irraggiungibile da http, e il problema diventa come farlo
eseguire dato che ï¿œ appunto irraggiungibile.
Allo scopo si mette in cgi-bin un wrapper, che sarï¿œ quel programma in C,
il quale una volta compilato sarï¿œ un file binario di poca utilitï¿œ per
chi lo scarica. A questo punto, l'indirizzo pubblico sarï¿œ:
http://tuositosalcazzo.fncl/cgi-bin/quelwrapper.cgi
(dove l'estensione .cgi mi fa capire che ï¿œ la versione compilata, e non
il sorgente, chiaramente!) il quale una volta eseguito andrï¿œ a invocare
lo script in /usr/local/bin, il quale a sua volta verrï¿œ quindi eseguito e
visualizzato in output sul browser del client; ma il sorgente non sarï¿œ
mai accessibile e quindi scaricabile.


 potrebbe scaricarlo e leggerlo, cosa che abbiamo detto voler impedire.
Sicuro che si possa scaricare/leggere?
Perche` lo script e` eseguito dal server http, che
dovrebbe poter essere configurato in modo da eseguire
senza passare il sorgente al client in nessun caso.
Comunque l'OP non menzionava web/cgi.
bye,
-- 
piergiorgio

 non si vede comunque. Ma dove hai letto che sara' usato da web? 
Boh, mi sembrava un problema tipico di chi non vuol far vedere gli
script via web, non so perchï¿œ mi sono fatto quest'idea.
Ad ogni modo, il principio non sposta di una virgola se anche fosse sul
filesystem, fai il wrapper binario in C che puoi su-idare tipo:
-rws--x--- ucomodo.gcomodo
Lo script lo metti con permessi:
-r-x------ ucomodo.gcomodo
A questo punto metti gli utenti che devono usare lo script nel gruppo
"gcomodo".
Potranno quindi avviare il wrapper in quanto questo ï¿œ eseguibile al
gruppo gcomodo; il wrapper partirï¿œ con su-id ucomodo, il quale utente ha
il permesso di avviare lo script. Tuttavia gli utenti del gruppo
gcomodo, direttamente, non potranno leggere lo script.
Cosï¿œ non l'ho provato, ma dovrebbe funzionare senza problemi: e ti
eviti di dare dei pericolosi su-id di root in giro (che non sono mai
belli nï¿œ sicuri).


 Comunque l'OP non menzionava web/cgi.
Vero, vedi allora l'altra risposta (non cambia molto, il principio resta
valido).


 d'accordo)
E neanche qui ti seguo; uno dei pochi motivi validi per ricorrere
 a questi metodi è proprio proteggere una informazione sensibile.

 ...
Una precisazione. sono perfettamente consapevole che molti 
sistemi ignorano setuid e setgid sugli script.

  a questi metodi è proprio proteggere una informazione sensibile.
Voglio dire che non ha senso cifrare uno script bash perche dentro c'è una 
password. Semplicemente devi trovare un modo di avere la password in un 
posto sicuro al cui solo script può accedere. Io normalmente per ste cose 
uso sudo + wrapper (bash).
-- 
Vide



Nessun sistema ignora setuid e setgid, a meno che non sia stato istruito 
a farlo.

 a farlo.
Linux ignora setuid sugli script, e a quanto ne so non e' possibile cambiare 
questo comportamento. Forse altri sistemi lo permettono.

 uso sudo + wrapper (bash).
 
Qui condivido. Uno su tre non è malaccio. ;-)

 Se poi il tuo sistema fa altrimenti hai un baco.
Adesso mi hai incuriosito perchè effetivamente stupiva anche me che non 
funzionasse. Provo e ritorno.
-- 
Vide

 funzionasse. Provo e ritorno.
Boh
vide@mypc:~$ cat a.sh
#!/bin/bash
echo "it works"
exit 0
vide@mypc:~$ ls -l a.sh
-rw-r--r-- 1 vide vide 36 2009-09-22 16:43 a.sh
vide@mypc:~$ chmod 700 a.sh
vide@mypc:~$ ls -l a.sh
-rwx------ 1 vide vide 36 2009-09-22 16:43 a.sh
vide@mypc:~$ ./a.sh
it works
vide@mypc:~$ chmod 0100 a.sh
vide@mypc:~$ ls -l a.sh
---x------ 1 vide vide 36 2009-09-22 16:43 a.sh
vide@mypc:~$ ./a.sh
/bin/bash: ./a.sh: Permission denied
vide@mypc:~$ cat a.sh
cat: a.sh: Permission denied
-- 
Vide

 Se poi il tuo sistema fa altrimenti hai un baco.
No, e' sancito da POSIX.

 deve essere almeno "+rw"
Ovviamente intendevo "deve essere almeno "+rx".

 sia un baco del kernel od un baco della bash.
E se fosse un baco di chi scrive cio`?

 Magari mi sfugge qualcosa ma un 0100 non funziona.
Ovviamente no, uno script deve poter essere letto per essere eseguito.
Puoi però, come ho già scritto nell'altro messaggio, scrivere un wrapper
binario che esegua il tuo script. Il wrapper lo metti su-id (essendo
binario il flag viene onorato), con permessi minimi ---s--x--- u.g
Lo script lo metti -r-x------ u.nogroup
L'utente che deve avviare il tutto, viene iscritto al gruppo g.
A questo punto, l'utente ha il permesso di avviare il wrapper, poiché il
gruppo cui appartiene ha i permessi di esecuzione.
Il wrapper però è su-idato e quindi avvierà a sua volta lo script coi
permessi di utente u, che può leggere ed eseguirlo.
Tuttavia, direttamente, l'utente non può leggere e quindi eseguire lo
script, che resta protetto dalla lettura.
Non l'ho testato direttamente, ma dovrebbe funzionare.


Vide wrote:

Dato che ho eseguito queste prove su un computer vero (di quelli che
occupavano una stanza intera) quando la bash non esisteva, ho fatto 
anche io delle prove.
$ file  easter ipcalc rot13
easter: ELF 32-bit LSB executable, [cut]
ipcalc: a /usr/bin/perl -w script text executable
rot13:  Bourne-Again shell script text executable
$ chmod 111 easter ipcalc rot13
$ ls -l  easter ipcalc rot13
---x--x--x 1 o1k o1k 35427 2004-04-16 09:58 easter*
---x--x--x 1 o1k o1k 28231 2008-11-17 20:31 ipcalc*
---x--x--x 1 o1k o1k   393 2005-01-31 12:35 rot13*
$ easter
12 4
$ ipcalc -n 
192.168.1.130/27
NETWORK=192.168.1.128
$ rot13 pippo.txt
/bin/bash: /home/o1k/bin/rot13: Permission denied
$ chmod 755 easter ipcalc rot13
[o1k@glick bin]$ rot13 pippo.txt
Pvnb n ghggv!
$
Un eseguibile ELF funziona, uno script Perl funziona, uno script BASH non 
funziona. C'è da indagare molto su questo
Ok il mio sistema ha un baco. 

 Per gli eseguibili e' diverso, li' si' che basta +x.
Che era appunto anche il mio ragionamento logico.
Però mallin dice che con uno script perl si che gli ha funzionato, e uno 
script perl è identico a un bash sotto il punto di vista dell'essere 
interpretato, no?
Come mai?
-- 
Vide

 ...
E questo cosa c'entra?
Twistedbrain ti chiami? 

 No, e' sancito da POSIX.
E qui si dovrebbe aprire una discussione molto interessante:
Perché POSIX stabilisce ciò?
Quale è il motivo?
Perchè vale solo per gli script BASH ma non per gli altri script?
C'è qualcosa di fondamentale dietro ciò?
È solo una convenzione di POSIX?

Vide wrote:

Questo e' diretto da perl FAQ:
"First of all, however, you can't take away read permission, because the 
source code has to be readable in order to be compiled and interpreted."
E in effetti a me non funziona se non e' readable:
$ chmod -r 
aa.pl
$ ./
aa.pl
Can't open perl script "./
aa.pl
": Permission denied
Non escludo che in qualche sistema, con qualche particolare configurazione, 
possa funzionare. A me non funziona.

 interpretato, no?
Purtroppo è stato un mio errore
Sul mio sistema ho due ipcalc, uno è la solita ciofeca che 
viene installata di default (e che pare serva al boot), l'altro è 
uno script Perl che fa cose molto interessanti ed utili.
Devo continuare?

 Quale è il motivo?
Perche' la shell deve *leggere* il file. La shell (o perl, o python) e' un 
processo eseguito in userspace come gli altri, quindi deve poter leggere il 
file.

 il file.
Caduto il velo dell'errore è come se gli occhi avessero 
visto la luce per la prima volta. Miracolo! Ci vedo! ;-)
Ok non è il momento per scherzare ma quello di fare penitenza.

Ciao e grazie innanzitutto!
Ho letto la pagina proposta: 
 >>
http://www.lilik.it/~mirko/gapil/gapilsu42.html
Quindi potrei includere lo script bash direttamente nel sorgente C e poi 
compilare il tutto?
Non mi � molto chiaro... mi date gentilmente una mano?
Grazie, ciao!
Francesco



 Ok il mio sistema ha un baco.
Ci deve essere qualcosa, perché a me uno script perl NON funziona se 
non è r-x per chi lo esegue.
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 obiezione non è valida.
Il loader è parte del kernel che se ne sbatte tranquillamente dei 
permessi e che viene lanciato dalla shell con una exec.  Immagino che 
controlli solo se è eseguibile da chi lancia il comando.


 sia un baco del kernel od un baco della bash.
Credo che la shell esegua il file, non essendo un binario lo apre per
vedere se contiene una shebang ma non lo pu� leggere e quindi
permission denied.
-- 
ValeRyo
CBR600F "Cerbero" - In vendita - 
http://www.slimmit.com/go.asp?7X0
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 
Ho provato anch'io, lo strano e' che lo stesso script bash con permessi 100
su Linux non viene eseguito, su OpenBSD si, penso che ci sia qualche cosa su 
come venga compilato bash o sul kernel (anche se mi sembra strano).
 Giovanni Bechis
-- 
/*
 * SnB - 
http://www.snb.it
 */

 Ok il mio sistema ha un baco. 
In linea di principio *qualunque* script deve essere
almeno leggibile, per essere eseguito.
Dato che l'interprete, che gira con i permessi utente,
deve poter fisicamente leggere il file script per poter
eseguire il tutto.
Cioe` deve fare fopen("script.xx","r"), se non ha i
permessi, ovviamente non puo` far nulla.
L'unica possibile eccezione e` root, dato che questo
sembrerebbe, in alcuni sistemi, capace di leggere i
file senza permesso di lettura (--x--x--x).
Per gli eseguibili binari (ELF od altro), il load viene
fatto dal kernel, il quale puo` benissimo ignorare i
permessi. Nello specifico "r", ma non "x".
bye,
-- 
piergiorgio

Damascus moment and he has seen the light, meanwhile he will be living
large on the profits of betrayal. , 
Guarda l'immagine cliccando 
http://attach.mynl.it/img?id=OTc4Ng
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it