# aiuto con nuova istallazione [RISOLTO]

## pigreco

Salve,

sto effettuando il set-up di due server gentoo identici: kernel x86_64-3.11.7-hardened-r1

le macchine sono identiche e le sto preparando in parallelo, ma ho due problemi distinti

su di una:

```
* Messages for package app-portage/gentoolkit-0.3.0.8-r2:

 * ERROR: app-portage/gentoolkit-0.3.0.8-r2::gentoo failed (prepare phase):

 *   python_export: no impl nor EPYTHON

 * 

 * Call stack:

 *     ebuild.sh, line   93:  Called src_prepare

 *   environment, line 3298:  Called distutils-r1_src_prepare

 *   environment, line 1045:  Called python_prepare_all

 *   environment, line 3146:  Called python_export_best

 *   environment, line 2943:  Called python_export '' 'EPYTHON' 'PYTHON'

 *   environment, line 2793:  Called die

 * The specific snippet of code:

 *               [[ -n ${impl} ]] || die "python_export: no impl nor EPYTHON"

 * 

 * If you need support, post the output of `emerge --info '=app-portage/gentoolkit-0.3.0.8-r2::gentoo'`,

 * the complete build log and the output of `emerge -pqv '=app-portage/gentoolkit-0.3.0.8-r2::gentoo'`.

 * The complete build log is located at '/var/tmp/portage/app-portage/gentoolkit-0.3.0.8-r2/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/app-portage/gentoolkit-0.3.0.8-r2/temp/environment'.

 * Working directory: '/var/tmp/portage/app-portage/gentoolkit-0.3.0.8-r2/work/gentoolkit-0.3.0.8'

 * S: '/var/tmp/portage/app-portage/gentoolkit-0.3.0.8-r2/work/gentoolkit-0.3.0.8'
```

sull'altra:

```
/usr/lib64/portage/bin/phase-helpers.sh: ./configure: /bin/sh: bad interpreter: Permission denied

 * ERROR: dev-lang/swig-2.0.9::gentoo failed (configure phase):

 *   econf failed

 * 

 * Call stack:

 *          ebuild.sh, line  93:  Called src_configure

 *        environment, line 140:  Called econf '--disable-ccache' '--with-pcre'

 *   phase-helpers.sh, line 577:  Called die

 * The specific snippet of code:

 *            die "econf failed"

 * 

 * If you need support, post the output of `emerge --info '=dev-lang/swig-2.0.9::gentoo'`,

 * the complete build log and the output of `emerge -pqv '=dev-lang/swig-2.0.9::gentoo'`.

 * The complete build log is located at '/var/tmp/portage/dev-lang/swig-2.0.9/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/dev-lang/swig-2.0.9/temp/environment'.

 * Working directory: '/var/tmp/portage/dev-lang/swig-2.0.9/work/swig-2.0.9'

 * S: '/var/tmp/portage/dev-lang/swig-2.0.9/work/swig-2.0.9'

>>> Failed to emerge dev-lang/swig-2.0.9, Log file:

>>>  '/var/tmp/portage/dev-lang/swig-2.0.9/temp/build.log'

 * Messages for package dev-lang/swig-2.0.9:

 * ERROR: dev-lang/swig-2.0.9::gentoo failed (configure phase):

 *   econf failed

 * 

 * Call stack:

 *          ebuild.sh, line  93:  Called src_configure

 *        environment, line 140:  Called econf '--disable-ccache' '--with-pcre'

 *   phase-helpers.sh, line 577:  Called die

 * The specific snippet of code:

 *            die "econf failed"

 * 

 * If you need support, post the output of `emerge --info '=dev-lang/swig-2.0.9::gentoo'`,

 * the complete build log and the output of `emerge -pqv '=dev-lang/swig-2.0.9::gentoo'`.

 * The complete build log is located at '/var/tmp/portage/dev-lang/swig-2.0.9/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/dev-lang/swig-2.0.9/temp/environment'.

 * Working directory: '/var/tmp/portage/dev-lang/swig-2.0.9/work/swig-2.0.9'

 * S: '/var/tmp/portage/dev-lang/swig-2.0.9/work/swig-2.0.9'
```

ogni suggerimento è fortemente apprezzato , grazie,

MaurizioLast edited by pigreco on Thu Jan 30, 2014 11:00 am; edited 1 time in total

----------

## pigreco

il problema di 'permission denied' durante l'emerge era generato da GRSEC

```
grsec: From 192.168.1.2: denied untrusted exec (due to not being in trusted group and file in non-root-owned directory) of /var/tmp/portage/dev-lang/swig-2.0.9/work/swig-2.0.9/configure by /var/tmp/portage/dev-lang/swig-2.0.9/work/swig-2.0.9/configure[ebuild.sh:18149] uid/euid:250/250 gid/egid:250/250, parent /usr/lib64/portage/bin/ebuild.sh[ebuild.sh:18130] uid/euid:250/250 gid/egid:250/250
```

ho risolto aggiungendo 'portage' al trusted group:

 *Quote:*   

> usermod -a -G wheel portage

 

questo può causare problemi di sicurezza?

mentre il problema 

```
ERROR: app-portage/gentoolkit-0.3.0.8-r2::gentoo failed (prepare phase):

 *   python_export: no impl nor EPYTHON

```

 è stato risolto con

```
ln -s /proc/self/fd /dev/fd
```

Maurizio

----------

## djinnZ

per la prima soluzione mi pare di capire che hai

```
GRKERNSEC_TPE_INVERT=Y

GRKERNSEC_TPE_TRUSTED_GID=10
```

e

```
FEATURES="userpriv"
```

quindi è l'unica strada per quel che so (ho sentito anche una versione paranoide dell'impostare il gid a zero nel kernel e via syscl abilitarlo per il wheel all'occorrenza, per quel che conta).

In realtà in giro si preferiscono soluzioni del genere disabilitare temporaneamente il TPE od usare l'impostazione di default (ovvero un singolo gruppo non è fidato).

Per la seconda il problema più o meno è lo stesso solo che hai dimenticato di impostare

```
GRKERNSEC_PROC_USERGROUP=y

GRKERNSEC_PROC_GID=10
```

se non erro, cosa che ti serve se vuoi sperare di usare X ed altre schifezze desktop su un sistema pax+grsec.

Non capisco a cosa serva al python andare a vedere /dev/fd a piè sospinto ma tant'è (ammetto che non lo ho mai digerito codesto interprete e continuo a credere che abbia preso piede solo perché dei nerd sfigati lo hanno spacciato come linguaggio da hacker a suo tempo).

Se l'obiettivo è un sistema server con console operativa, od una via di mezzo tra server e desktop, o rendere un desktop più sicuro sei più che a posto.

Se stai predisponendo qualcosa di più allora sappi che devi rivedere le tue scelte.

Soprattutto sul secondo problema ci sono ampi e documentatissimi exploit in rete.

Da notare che se quello che stai cercando di metter su è un webserver potresti documentarti su CONFIG_GRKERNSEC_SYMLINKOWN, che se non mi sbaglio è stata introdotta apposta per casi come il tuo (non esattamente il mio perché non ho il webserver, quindi non ho approfondito).

i miei due centesimi ... di lira (o perle ai porci visti i soggetti che ultimamente bazzicano codesto forum dimenticato da dio, più che da gli uomini¹).  :Twisted Evil:   :Twisted Evil:   :Twisted Evil:  

Inutile (si fa per dire) sottolineare che se trovi utile il contenuto di questo messaggio (dopo averlo verificato) potresti ringraziarmi traducendolo nell'odioso idioma della losca e grassatrice albione a beneficio anche di chi non ha la sventura di vivere in codesta landa sempre più desolata².

¹ dimm....

² ogni riferimento alle vicende della FIAT, della sciaguratissima legge elettorale, della faccia di c[ensura] di certi politici etc. è puramente ... intenzionale.

----------

## pigreco

ciao grazie per la risposta, premetto che non ho le tue conoscenze e non sono in grado di pronunciarmi mi limito a risponderti

 *Quote:*   

> per la prima soluzione mi pare di capire che hai
> 
> /etc/kernels/kernel-config-x86_64-3.11.7-hardened-r1:
> 
> GRKERNSEC_TPE_INVERT=Y 
> ...

 

si

 *Quote:*   

> e
> 
> /etc/portage/make.conf:
> 
> FEATURES="userpriv"

 

no

 *Quote:*   

> Per la seconda il problema più o meno è lo stesso solo che hai dimenticato di impostare
> 
> /etc/kernels/kernel-config-x86_64-3.11.7-hardened-r1:
> 
> GRKERNSEC_PROC_USERGROUP=y 
> ...

 

perdona ma non ho capito la relazione   :Embarassed: 

 *Quote:*   

> Non capisco a cosa serva al python andare a vedere /dev/fd a piè sospinto ma tant'è (ammetto che non lo ho mai digerito codesto interprete e continuo a credere che abbia preso piede solo perché dei nerd sfigati lo hanno spacciato come linguaggio da hacker a suo tempo). 
> 
> Se l'obiettivo è un sistema server con console operativa, od una via di mezzo tra server e desktop, o rendere un desktop più sicuro sei più che a posto. 
> 
> Se stai predisponendo qualcosa di più allora sappi che devi rivedere le tue scelte. 
> ...

 

potresti indicarmi dove documentarmi sulla problematica?

 *Quote:*   

> Da notare che se quello che stai cercando di metter su è un webserver potresti documentarti su CONFIG_GRKERNSEC_SYMLINKOWN, che se non mi sbaglio è stata introdotta apposta per casi come il tuo (non esattamente il mio perché non ho il webserver, quindi non ho approfondito). 

 

è un server per cui non è previsto il servizio web ma a scanso di problemi futuri l'ho abilitato

per la traduzione ci posso provare, non è che il mio inglese sia un granché..

grazie,

Maurizio

----------

## djinnZ

 *pigreco wrote:*   

> 
> 
> ```
> FEATURES="userpriv"
> ```
> ...

 invece si, controlla con emerge --info. Od avrai provato ad avviare emerge come utente non-root e quindi l'automake viene eseguito da portage su di una directory di proprietà di portage. Il TPE, come lo hai impostato, non fa altro che impedire di avviare tutti gli eseguibili che non siano di proprietà di root o di wheel (e solo leggibili agli altri) in una dir di proprietà degli stessi.

Od aggiungi una eccezione ad hoc per rendere /var/tmp/portage "affidabile" (complicato davvero, diedi uno sguardo ad un post ma non era convincente), od esegui portage da root con tutte le conseguenze del caso.

Il rischio effettivo sarebbe nel momento in cui lasci qualcosa in /var/tmp/portage (FEATURES="keeptemp keepwork") poichè è facile che un devel si scordi di rendere l'automake od il makefile protetti da scrittura. Scrivendoci sopra sarebbe possibile far danno. Tutto qui. *pigreco wrote:*   

> perdona ma non ho capito la relazione   

 Hai attivato le restrizioni su proc quindi /proc/self non dovrebbe essere accessibile (per questo non crea il link, IMHO).

Verifica perché sono sotto scadenza/molestia/dispendiosa_vessazione a carattere estorsivo/intimidatorio/insulso da parte dell'AdE (spesometro) quindi non ho tempo e modo di applicarmi e verificare il meccanismo esatto (sto scrivendo "a braccio" ed a memoria, scarsa) ma, con le opzioni che ti ho indicato, istruisci il kernel a consentire l'accesso agli utenti in wheel, come hai fatto per il TPE (almeno questo ricordo, è una vita che non metto mano alle policy ed alla configurazione di grsec).

Oppure non hai caricato correttamente le policy.

Per i problemi collegati prova a fare una ricerca per "/proc/self/fd" su google o sul sito di grsec. Dovestri trovare anche gli esempi su google, video incluso.

L'exploit più diffuso è attraverso il php sempre se non ricordo male. Per questo ho parlato di webserver.

Ovvio che non esiste un sistema sicuro od insicuro, solo un sistema ragionevolmente sicuro. Quindi puoi accettare una qualche mezza vulnerabilità in cambio dell'operatività.

Lo dico perché ho letto spesso discorsi del tenore "se non è pienamente hardenizzato puoi fare a meno di grsec", lo so che sembra da pazzi ma sono i tempi tristi che viviamo (e l'abitudine di sparare slogan, tipica depravazione della civiltà anglofona).

----------

## pigreco

ok sei stato esaustivo,farò tesoro dei tuoi consigli

grazie ancora,

Maurizio

----------

