# [Sicurezza] Limitare l'accesso a GCC?

## .:deadhead:.

Dopo aver installato un server seguendo i suggerimenti qui esposti, mi rimane giusto un dubbio.

In un server di produzione, orientato un minimo alla sicurezza, la presenza di GCC è superflua, anzi è potenzialmente pericolosa. Tutte le altre distro infatti usano pacchetti precompilati e non ne hanno bisogno.

In Gentoo però GCC è necessario...  :Confused: 

ESCLUDENDO l'opzione packages, perchè magari il server è l'unica macchina linux presente in una LAN di client windows-only, come si potrebbe rendere la presenza di GCC meno pericolosa?

Io avevo pensato al limitarne l'uso solo a root, come già avviene per portage.

E' una buona soluzione? Come fare in pratica? Altre proposte?

iauz

deadhead

----------

## randomaze

 *.:deadhead:. wrote:*   

> In Gentoo però GCC è necessario... 
> 
> 

 

Forse una soluzione del tipo:

```

#quickpkg gcc

#emerge -C gcc

```

dovrebbe andare, poi quando hai bisogno:

```

#emerge -k gcc

#emerge sync && emerge -uD world

...

#emerge -C gcc

```

naturalmente non provare una cosa simile in produzione perché per motivi che adesso mi sfuggono potrebbe non funzionare....

 *.:deadhead:. wrote:*   

> 
> 
> Io avevo pensato al limitarne l'uso solo a root, come già avviene per portage.
> 
> E' una buona soluzione? Come fare in pratica? Altre proposte?
> ...

 

Diciamo che sarebbe una soluzione per evitare che lìattaccante sfrutti il gcc per guadagnare privilegi sulla macchina locale, ma se l'attaccante riesce ad arrivare ai privilegi di root in locale potrebbe servirsi del gcc per compilare tool con i quali attaccare altre macchine.

Per fare così dovrebbe bastare:

```

chmod go-rx `which gcc`

```

P.S. La security-guide c'é anche in italiano, dato che qualcuno l'ha tradotta dagli la soddisfazione di sapere che qualcuno la legge  :Razz: 

----------

## MyZelF

Tienici informati se provi la soluzione di randomaze... ho spesso consigliato "a parole" un metodo simile, ma non avendone mai verificato l'efficacia non mi sono mai sbilanciato troppo...   :Wink: 

----------

## GNU/Duncan

Scusate... un chiarimento...

Non sarebbe possibile fare cross compiling su un'altra macchina, pacchettizzare il tutto e poi installare soltanto sul server?

----------

## federico

Ci sono due cose che mi sfuggono...

La prima e' che non sono daccordo sul binomio "sicurezza"-"pacchetto precompilato", io mi fido solamente di quello che ho compilato io come dico io... 

La seconda e' che non capisco la pericolosita' del gcc nella tua situazione, se ho ben capito sul server non dovrebbero esserci utenti ma solamente servizi che girano, giusto?

In questo caso e' necessario sistemare tutti i processi per essere lanciati in ambiente di chroot chiaramente senza compilatore. (E patchare in maniera adeguata il kernel)

----------

## fedeliallalinea

 *GNU/Duncan wrote:*   

> Non sarebbe possibile fare cross compiling su un'altra macchina, pacchettizzare il tutto e poi installare soltanto sul server?

 

Si penso sia possibile ma implica che devi avere una macchina in piu' per la compilazione.

----------

## GNU/Duncan

Deve identica però? 

Anche fosse un AMD e il server fosse intel posso usare -march specifiche facendo cross compiling?

----------

## .:deadhead:.

 *GNU/Duncan wrote:*   

> Non sarebbe possibile fare cross compiling su un'altra macchina, pacchettizzare il tutto e poi installare soltanto sul server?

 

Questa sarebbe in linea teorica la soluzione migliore, in quanto non avrei bisogno del GCC...  :Smile: 

Ma l'ho esclusa a priori perchè quel server è l'unica macchina linux all'interno della LAN e non ho tempo/risorse per gestire una soluzione così "macchinosa".  :Sad: 

Già che hai citato la pacchettizazione, per fare ciò che tu dici, dovrei pacchettizzare usando le medesime USE flag del server, giusto?  :Question: 

----------

## federico

Secondo me il problema sicurezza e' da porsi in maniera differente, ovvero NON rimuovere gcc in modo che un presunto attaccante possa utilizzarlo ma come evitare che l'attaccante arrivi ad usare gcc...

Ovvero...

Non e' gcc il male su una macchina, e' una macchina non sicura il male di se stessa! Sicuramente non e' eliminando gcc che eviterai problemi; un esempio ? Trovo una falla remota in apache, accedo come root, installo sulla tua macchina pacchetti che ho precompilato sulla mia e inoltre gia' che ci sono emergo il gcc che tu hai tolto...

----------

## fedeliallalinea

 *federico wrote:*   

> Trovo una falla remota in apache, accedo come root, installo sulla tua macchina pacchetti che ho precompilato sulla mia e inoltre gia' che ci sono emergo il gcc che tu hai tolto...

 

Mi stavo domandando la stessa cosa. Una volta che una ha l'accesso root non vedo che differenza faccia avere gcc o no.

----------

## federico

Ed e' per questo che il mio consiglio base e' iniziare a preparare una macchina con un buon kernel patchato e lanciare tutti i demoni presenti con un sistema di chroot (che chiaramente al suo interno esclude gcc).

Se ci sono degli utenti obbligarli a una policy di password con una discreta entropia e obbligarli a cambiare la password ogni tot (e se non sbaglio sul gentoo security howto c'e' spiegato come).

Questi due spunti iniziali ma di idee se ne possono sviluppare diverse.

----------

## xchris

 *federico wrote:*   

> Trovo una falla remota in apache, accedo come root, installo sulla tua macchina pacchetti che ho precompilato sulla mia e inoltre gia' che ci sono emergo il gcc che tu hai tolto...

 

concordo!

a quel punto dovresti rimuovere la maggior parte delle applicazioni.

Nessun tipo di file transfer...->ne lynx,wget.... ne ftp ..ne ssh

praticamente la devi radere al suolo se vuoi perseguire la strada...."Mo che sei entrato ti blocco"

meglio tener aggiornata la macchina a livello kernel e demoni vari.

ciao

----------

## randomaze

 *federico wrote:*   

> Non e' gcc il male su una macchina, e' una macchina non sicura il male di se stessa! Sicuramente non e' eliminando gcc che eviterai problemi; un esempio ? Trovo una falla remota in apache, accedo come root, installo sulla tua macchina pacchetti che ho precompilato sulla mia e inoltre gia' che ci sono emergo il gcc che tu hai tolto...

 

Su questo siamo daccordo. Però in sistema protetto l'attaccante che arriva a sfruttare la falla di apache "si presume" che arrivi al sistema ed accede come utente httpd/nobody/quelchele.

Una volta che é riuscito ad arrivare dentro il sistema il problema seguente é impedirgli di elevare i privilegi dell'utente con cui é entrato, quindi impedirgli di portare materiale dall'esterno e impedirgli di costruirsi i suoi tool in loco.

Siamo daccordo che lasciare le falle perché "tanto ho tolto il gcc" é una bestialità  :Mr. Green: 

----------

## federico

Effettivamente la questione utente locale e' tutta da discutere...

Il problema e' che esistono anche diverse applicazioni che in passato (chiaramente utilizzando l'ultima versione aggiornaterrima e' + difficile essere soggetto a questo attacco) hanno offerto un pratico accesso root in remoto (e ogni tanto esce qualche advisory di questo tipo)

----------

## randomaze

 *federico wrote:*   

> Effettivamente la questione utente locale e' tutta da discutere...

 

Ovviamente anche il chroot che hai citato mentre rispondevo....  le tecniche di sicurezza sono molteplici e una non esclude l'altra. 

Poi é vero che se la macchina é aggiornata già tagli fuori il 95% dei possibili attaccanti. Ma il restante 5% é il problema maggiore...  

(e, magari, dopo che ti sei fatto tutte ma proprio tutte le procedure di sicurezza possibili e immaginabili, uno dei tuoi sviluppatori ti mette fuori un form php fatto con i piedi...)

----------

## .:deadhead:.

 *federico wrote:*   

> Secondo me il problema sicurezza e' da porsi in maniera differente, ovvero NON rimuovere gcc in modo che un presunto attaccante possa utilizzarlo ma come evitare che l'attaccante arrivi ad usare gcc...

 

Se arrivano a compromettere root, c'è poco da fare  :Very Happy: 

Ciò che volevo ottenere è che, nel malaugurato caso in cui mi venga crackato un user account, l'attacker poi si trovi un ambiente il meno utile possibile ad una scalata di privilegi. Per questo chiedevo se si potesse solo inibire agli user normali l'uso del GCC. Grecurity aiuta molto ma volevo togliermi anche questo "sfizio".

Ha senso come ragionamento oppure è inutile?  :Wink: 

----------

## .:deadhead:.

 *randomaze wrote:*   

> Una volta che é riuscito ad arrivare dentro il sistema il problema seguente é impedirgli di elevare i privilegi dell'utente con cui é entrato, quindi impedirgli di portare materiale dall'esterno e impedirgli di costruirsi i suoi tool in loco.
> 
> Siamo daccordo che lasciare le falle perché "tanto ho tolto il gcc" é una bestialità 

 

Ti hanno regalato una sfera di cristallo di recente?   :Razz: 

E' proprio quello che intendevo dire!

----------

## BlueRaven

 *randomaze wrote:*   

> Una volta che é riuscito ad arrivare dentro il sistema il problema seguente é impedirgli di elevare i privilegi dell'utente con cui é entrato, quindi impedirgli di portare materiale dall'esterno e impedirgli di costruirsi i suoi tool in loco.

 

Sinceramente, non vedo come rimuovere gcc possa aiutare in questo: forse da utente normale non posso emergere quello di sistema, ma nulla mi impedisce di caricarmene uno compilato staticamente e usare quello per compilare i vari exploit locali.

Oppure me li precompilo sulla mia macchina e li uso direttamente binari.

Il problema rimane sempre impedire di entrare, una volta che uno è entrato - a qualunque livello di privilegi - della macchina non ti puoi più fidare.

Il tutto IMHO, ovviamente!  :Smile: 

----------

## .:deadhead:.

 *federico wrote:*   

> Ci sono due cose che mi sfuggono...
> 
> La prima e' che non sono daccordo sul binomio "sicurezza"-"pacchetto precompilato", io mi fido solamente di quello che ho compilato io come dico io...

 Senza contare il fatto della necessità di avere un'altra macchina per compilare etc etc

 *federico wrote:*   

> La seconda e' che non capisco la pericolosita' del gcc nella tua situazione, se ho ben capito sul server non dovrebbero esserci utenti ma solamente servizi che girano, giusto?

 

La macchina fa da file server con Samba3+ClamAV e OpenSSH per la gestione [la macchina è senza tastiera,mouse e video, lontano dall'ufficio].

Il kernel è monolitico con applicate le patch del progetto Grsecurity.

 *federico wrote:*   

> 
> 
> In questo caso e' necessario sistemare tutti i processi per essere lanciati in ambiente di chroot chiaramente senza compilatore. (E patchare in maniera adeguata il kernel)

 

----------

## .:deadhead:.

 *BlueRaven wrote:*   

> Sinceramente, non vedo come rimuovere gcc possa aiutare in questo: forse da utente normale non posso emergere quello di sistema, ma nulla mi impedisce di caricarmene uno compilato staticamente e usare quello per compilare i vari exploit locali.
> 
> Oppure me li precompilo sulla mia macchina e li uso direttamente binari.
> 
> Il problema rimane sempre impedire di entrare, una volta che uno è entrato - a qualunque livello di privilegi - della macchina non ti puoi più fidare.
> ...

 

Questo è vero, io ragiono analizzando una mia realtà, dove

- il server è in una LAN

- dietro ad un firewallino HW

- il firewallino collegato alla rete [no ip statico]

- Il firewallino lascia passare verso l'esterno solo il traffico che il server

  genera verso il server di aggiornamento dell'antivirus e per portage

- Con calma mi implemento le mie reolette di IPTables per bloccare tutto

  tranne gli accessi in entrata a samba e in uscita per portage e antivirus

- Gli utenti non vedono una console ma solo usano lo spazio sul disco

In questo caso, una soluzione come quella di Randomaze è inutile?

```
chmod go-rx `which gcc` 
```

----------

## federico

Scusa ma se non ci sono utenti attivi il problema qual'e..

Metti tutti i servizi che ti servono in chroot e buonanotte al secchio.

Un qualcuno ti exploita samba? Tu te ne sbatti xke' tanto e' in chroot!

----------

## randomaze

 *federico wrote:*   

> Un qualcuno ti exploita samba? Tu te ne sbatti xke' tanto e' in chroot!

 

Ci sono anche tecniche di uscita dal chroot....

EDIT: ad esempio questa...

----------

## federico

Conosco ma se non sbaglio (non ho provato ultimamente a rompere un chroot) le opzioni del grsecurity riguardanti chroot servono ad evitarlo, giusto ?

----------

## randomaze

 *federico wrote:*   

> Conosco ma se non sbaglio (non ho provato ultimamente a rompere un chroot) le opzioni del grsecurity riguardanti chroot servono ad evitarlo, giusto ?

 

il problema é che devi anche pensare che non sai mai cosa c'é in giro... per una che ne blocchi nulla vieta che ce ne sia un'altra ancora non troppo nota.

Fare le cose per bene significa anche riuscire a prevenire l'ignoto... (poi dipende se ne vale la pena dato il tempo impiegabile...)

----------

## federico

Piu' che altro io sono dell'idea che devi cercare di fare la cosa pensandola bene fin dall'inizio, facendola sia in un modo o nell'altro...

IMHO tuttavia la coperta e' quella che e', se la tiri dalla testa rimani scoperto sui piedi  :Smile:  [e puoi prevedere un determinato numero di possibilita' ma non tutte]

----------

## randomaze

 *federico wrote:*   

> IMHO tuttavia la coperta e' quella che e', se la tiri dalla testa rimani scoperto sui piedi  [e puoi prevedere un determinato numero di possibilita' ma non tutte]

 

Si però occorre cercare di sfruttare la coperta al meglio  :Wink: 

----------

## .:deadhead:.

 *federico wrote:*   

> Scusa ma se non ci sono utenti attivi il problema qual'è..

 

Come utenti attivi intendi utenti che si loggano sul server, giusto?

Io ho creato sul server tutti gli utenti della mia LAN così da dar loro una home e poter gestire le quote. Ma a parte questo l'esistenza del server è completamente trasparente ai client. Le password degli user sui client WinXP Home e quella sul server sono uguali, così windows monta ad ogni utente automaticamente la sua  partizione condivisa.

----------

## federico

si era esattamente quello che intendevo, in linea di massima nessuno di loro ha bisogno di una shell "valida", devi controllare ma forse samba nn ha bisogno della bash come fileserver..

----------

