Ciao, tu che stai leggendo, se sei un purista ignora questa mail
A volte sulle macchine devo dare accesso ad alcuni utenti esterni
(supporti, clienti, consulenti). In questi script vi sono procedure
aziendali - si direbbe segreti industriali - che automatizzano la nostra
infrastruttura oltre che metodi comodi di recupero credenziali, e trovo
inconveniente che qualcuno possa fare cat myscript.rb, leggere, copiare,
o anche modificare accidentalmente questi script.
So che dall’avvento delle release >= 1.9.x stata migliorata la VM e vi
sono interpreti alternativi, come RBX o JRuby, che creano bytecode.
Scrivo per chiedere se potete consigliarmi qualche best practice o
condividere esperienze (compatibilit, problemi) per compilare gli
script di sistema che scrivo in Ruby in binari eseguibili. Questi binari
devono girare su GNU/Linux x86_64. Li distribuisco automaticamente con i
miei .rpm o .deb privati o con puppet.
sono interpreti alternativi, come RBX o JRuby, che creano bytecode.
Scrivo per chiedere se potete consigliarmi qualche best practice o
condividere esperienze (compatibilit, problemi) per compilare gli
script di sistema che scrivo in Ruby in binari eseguibili. Questi binari
devono girare su GNU/Linux x86_64. Li distribuisco automaticamente con i
miei .rpm o .deb privati o con puppet.
Cosa ne pensate?
Al codemotion o al rubyday, 2012 o 2013 (sorry, la mia memoria non
riesce a fare di meglio :D) c’era una presentazione di Github in cui,
tra le altre cose, spiegavano come offuscano il codice ruby per le
installazioni che fanno direttamente dai clienti enterprise.
Le vaghe indicazioni potrebbero aiutarti nel ricercare la presentazione
online
Per semplicit, non essendo probabilmente script enormi e neanche usati tutti i
giorni, forse ti conviene un binario in C o in Go.
In realt sono piuttosto complessi perch automatizzano setup,
aggiornamenti, backup e quant’altro… Li modifico spesso aggiungendo o
togliendo pezzi (poi si autodistribuiscono). Ti prego non dirmi che devo
riscriverli in C
Al codemotion o al rubyday, 2012 o 2013 (sorry, la mia memoria non riesce a
fare di meglio :D) c’era una presentazione di Github in cui, tra le altre cose,
spiegavano come offuscano il codice ruby per le installazioni che fanno
direttamente dai clienti enterprise.
Le vaghe indicazioni potrebbero aiutarti nel ricercare la presentazione online
la compilazione pu andare solo se vuoi difenderti da cat myscript.rb e
poco altro, non la considerare una sicurezza per le credenziali presenti
nello script, se necessaria adotta soluzioni alternative.
la compilazione pu andare solo se vuoi difenderti da cat myscript.rb e
poco altro, non la considerare una sicurezza per le credenziali presenti
nello script, se necessaria adotta soluzioni alternative.
S, desidero proprio questo: che quello che pubblico su Github sia
pubblico, ma che le procedure interne aziendali (proprio le cose che
facciamo, in un determinato ordine con determinate condizioni con
determinate ottimizzazioni e sotto determinate regole) non possano
essere lette, almeno non cos facilmente
Ciao Fabrizio, faccio la domanda banale. Non riesci a risolverla con
le permission Unix?
Compilare non ti cautela del tutto, se un segreto quello che vuoi
difendere, con xargs recuperi le stringhe… e uno bravo ti
disassembla l’ELF.
Se vuoi compilare allora devi necessariamente anche offuscare il
compilato per evitare che qualcuno abbia accesso a quelle
informazioni.
Altrimenti la cosa che puoi fare questa. Dai l’ownership del file
.rb ad un utente e 0 a group e other. Crei un launcher in C, lo fai
suid a root [1] (attenzione), e nel launcher cambi l’euid e fai la
system di “ruby file.rb”.
Pi semplice? Fai firmare una NDA ai consulenti esterni
[1] (attenzione) il programma suid a root devi farlo in modo che non
accetti input dall’esterno, non onori alcuna variabile d’ambiente e
quindi non possa essere usato in una privilege escalation.
Ti posso, aggiungere che tempo fa girando su internet ho trovato un
prodotto simile a ocra, a pagamento, che sembrava molto completo,
purtroppo non riesco a ritrovare il link…
