Jump to content

[INFO] Considerazioni sulla sicurezza di 10.11


Ciro82
 Share

48 posts in this topic

Recommended Posts

Da qualche giorno pensavo se scrivere oppure no due righe in merito a questo problema, ma visto che ci sono lo faccio.

 

Mi riferisco alla questione "rootless=0" 

Stando a quel che dice Pike R. Alpha, El Capitan avviato con rootless=0 è ALTAMENTE rischioso, perché in pratica rootless=0 bypassa TUTTI i parametri di sicurezza implementati in OS X 10.11. 

Cosa significa tutto questo? Beh, che non si limita a bypassare il controllo kext non firmati in S/L/E ma bypassa tutta una serie di sicurezze che sono fondamentali per tenere al sicuro i dati degli utenti, visto che è emerso che è possibile avere accesso completo al sistema di tutti gli utilizzatori del famoso bootlader UEFI.

Com'è possibile direte voi? E' possibile farlo distribuendo un bootloader con il file boot.efi modificato a dovere (non entro nei particolari). 

Ora tutti diranno che accettano il rischio e preferiscono avere la possibilità di usare il sistema a scapito della sicurezza, bene ognuno è libero di fare come vuole, però era mia priorità avvisare.

Detto questo, come ho già scritto in un thread, El Capitan sulle mie macchine non lo installo fino a che il team di sviluppo di un bootloader non mi dice che ha trovato la soluzione a questo pericoloso problema.

 

EDIT: Vi state chiedendo se questo discorso vale anche per Yosemite? La risposta è NO, non vale per 10.10 perché la sicurezza è gestita in modo diverso. Su El Capitan hanno integrato nella gestione della sicurezza anche la verifica dei kext non firmati, mentre su Yosemite questa verifica è una cosa a se stante, ecco perché se su Yosemite serve avere kext-dev-mode=1 per poter utilizzare kext non firmati, su El Capitan kext-dev-mode=1 non serve più (serve solo rootless=0

  • Like 5
Link to comment
Share on other sites

Concordo su ciò che hai scritto, sono felice che qualcuno abbia sottolineato  il pericolo legato a tale boot flag.

Ad oggi per quello che vedo e leggo anche i "metodi alternativi"a tale flag, si rivelano alla fine "tradotti nella medesima cosa".

Una backdoor....aperta.

Chiavi di casa alla portata di tutti... 


Edit= Concordo anche sul tuo edit

Ho fatto numerose installazioni, sempre e solo usando rootless=0


Edit 2= Aggiungo che ognuno è libero di fare ciò che vuole, ma quello che importa, secondo me, è essere consapevoli di cosa stiamo facendo e dei rischi che possiamo correre.

  • Like 3
Link to comment
Share on other sites

http://www.insanelymac.com/forum/topic/306530-os-x-el-capitan-dps-builds/page-22

 

Eccetto che per l'installazione (almeno credo, visto che non posso provarlo) rootless=0 si può' omettere ora

RtVariables

CsrActiveConfig

0x67

BooterConfig

0x28

 

aggiungendo questo al config, non hai bisogno di rootless=0

 

qui di seguito la spiegazione, fatta da @pokenguyen:

0x67 = Enable unsigned kexts + Enable NVRAM edit + Enable /System access

0x65 = Enable unsigned kexts + Enable NVRAM edit + Disable /System access

 

Ma la "sicurezza"?

  • Like 1
Link to comment
Share on other sites

Ciao ragazzi, 

a quanto pare, Apple ha intenzione di non offrire la possibilità di usare tale bootflag nella versione finale di El Capitan, o permettere l'uso di kext non firmati.

 

Ma non ce' da preoccuparsi, perché Pikeralpha è riuscito ad avviare senza rootless con i kext iniettati e con la SIP (System Integrity Protection) avviata come su un normale Mac.

 

Bisogna tenere presente che il problema della sicurezza e' presente non solo nei nostri hackintosh ma anche su i normali mac e non e' solo veicolato dai kext che eseguono le nostre macchine, ma oltre che da mille fattori, anche dal software che usiamo....

 

Per essere completamente sicuri oltre che usare solo kext firmati o di provenienza più che lecita dovremmo usare solo app controllate da Apple (!?!?!?)

 

e Disconnetterci.

  • Like 1
Link to comment
Share on other sites

Ciao ragazzi, 

a quanto pare, Apple ha intenzione di non offrire la possibilità di usare tale bootflag nella versione finale di El Capitan, o permettere l'uso di kext non firmati.

 

Ma non ce' da preoccuparsi, perché Pikeralpha è riuscito ad avviare senza rootless con i kext iniettati e con la SIP (System Integrity Protection) avviata come su un normale Mac.

 

Bisogna tenere presente che il problema della sicurezza e' presente non solo nei nostri hackintosh ma anche su i normali mac e non e' solo veicolato dai kext che eseguono le nostre macchine, ma oltre che da mille fattori, anche dal software che usiamo....

 

Per essere completamente sicuri oltre che usare solo kext firmati o di provenienza più che lecita dovremmo usare solo app controllate da Apple (!?!?!?)

 

e Disconnetterci.

Tanti dei miei ringraziamenti vanno a Pikeralpha.... ;)

Ma ad oggi usando tale boot flag, o arginando il problema metodo sopra descritto con clover....

Ripeto: la sicurezza?

Faccio questa domanda perché ho visto le modifiche che sono state apportate nell'ultima versione 3253

  • Like 2
Link to comment
Share on other sites

con rootless l'intera sip viene disattivata 

al contrario usando il metodo descritto da piker solo i kext selezionati dovrebbero avere la possibilità di essere caricati

mantenendo attivo il sip

 

con questo si intende "maggiore" sicurezza...

  • Like 1
Link to comment
Share on other sites

Quindi credo che sia opportuno dire di usare sempre il metodo di Pikeralpha, ne va della propria sicurezza.

Se posso vorrei mettere i link, così che altri utenti possano rendersi conto con i propri occhi di ciò di cui stiamo parlando.

se non è un problema, ovviamente...

  • Like 1
Link to comment
Share on other sites

Onestamente penso sia meglio aspettare l'uscita della versione finale di El Capitan.

 

Comunque posta ovviamente!

Pienamente d'accordo... :yes:

comunque visto che tante persone stanno provando El Capitan, e visto che ne abbiamo parlato, credo sia corretto dare l'opportunità a tutti di sapere...

Personalmente adoro saper cosa faccio, nel caso: libero di fare,consapevole dei rischi, e come poterli diminuire o eliminare se ne ho l'opportunità.

Ecco i link:

https://pikeralpha.wordpress.com/2015/07/08/el-capitan-should-not-be-booted-with-rootless0/

https://pikeralpha.wordpress.com/2015/07/28/apples-kext-signing-bypassed/

  • Like 3
Link to comment
Share on other sites

Sono d'accordo con tutti i rischi che si incorrono usando un SO beta con le protezioni disattivate, siamo tutti nella stessa barca.

 

Ma penso anche che un sistema "pulito", magari Windows attivato con qualche "tool trovato chissadove" con installate 10 o 15 applicazioni e giochi "pirata" tirati random via torrent con installers non ufficiali, 

 

non sia certo più sicuro.

 

:turbin:

Link to comment
Share on other sites

<key>RtVariables</key>

<dict>

<key>CsrActiveConfig</key>

<string>0x67</string>

<key>BooterConfig</key>

<string>0x28</string>

</dict>

 

Dopo l'installazione dei kext con questa configurazione e Rootless=0

 

Si può riportare la stringa CsrActiveConfig a 0x0 per riattivare il SIP e fino a che non si ricostruisce la cache dei kext tutto funzionerà a dovere...

io ho kexts per ethernet mouse e audio.

 

fteqmf.png

  • Like 1
Link to comment
Share on other sites

anche rootless...

e anche durante l'installazione...

 

ovviamente essendo ancora in beta tutto potrebbe cambiare... :/

scusami, ma leggo sul forum che aggiungendo tale "righe" al config, rootless=0 non serva più per installare.

Leggo anche che serve kext-dev-mode=1 in aggiunta a rootless=0 per installare, e questo come già detto nel secondo post, almeno nel mio caso non è così.

Per quello che so, forse mi sbaglio, ma rootless=0 già comprende kext-dev-mode.

dimostrato dal fatto delle numerose installazioni da me fatte solo con un bootflag.

Alcune volte....mi trovo un po' "spiazzato".... :drool:

Link to comment
Share on other sites

Rootless=0 è indispensabile sia per installare kext che per ricreare le cache?

oppure basta tale configurazione? (0x67)

Per installazione serve rootless=0 fatta modificare il config

<key>RtVariables</key>
<dict>
<key>CsrActiveConfig</key>
<string>0x67</string>
<key>BooterConfig</key>
<string>0x28</string>
</dict>

Installare i vari kext in L/E ho S/L/E riparare permessi e cache 

Modificare il config 

<key>CsrActiveConfig</key>
<string>0x00</string>

Per abilitare SIP

 

Fabio

  • Like 2
Link to comment
Share on other sites

Sarebbe utile avere una Wiki interna al forum italiano con tutte queste considerazioni...

Altrimenti è pressoché inutile fare i professori dopo che il problema è stato sollevato, o mi sbaglio? 

Non prendetela a male ma ho aperto questo thread proprio per far venire a galla questi problemi sulla sicurezza, visto che finora nella sezione italiana nessuno ne ha parlato approfonditamente..

  • Like 3
Link to comment
Share on other sites

secondo me-

servirebbe molta più conoscenza - credo che in questa comunità che ci si aiuta nessuno metterebbe a porte chiuse delle cose devono essere sapute -

tutti siamo solidali e cerchiamo di aiutarci-

  • Like 1
Link to comment
Share on other sites

Beh Ciro sono discussioni che tuttora sono ancora calde nel forum internazionale e tra gli sviluppatori dei vari bootloader, hai fatto bene ad aprire il thread, qui nessuno fa il professore, stiamo solo condividendo ciò che sappiamo...

 

:)

 

@copil

 

penso che insanelymac sia un ottima risorsa

  • Like 1
Link to comment
Share on other sites

Beh Ciro sono discussioni che tuttora sono ancora calde nel forum internazionale e tra gli sviluppatori dei vari bootloader, hai fatto bene ad aprire il thread, qui nessuno fa il professore, stiamo solo condividendo ciò che sappiamo...

 

:)

 

Infatti sto seguendo il discorso nel forum internazionale ed ho aperto la discussione proprio per far luce su questi sviluppi, visto che non tutti frequentano le sezioni internazionali ;)

  • Like 1
Link to comment
Share on other sites

sembra na serie televisiva anni 90 

bustarelle e robe varie XD

 

 

Infatti la cosa mi ha abbastanza schifato a dirla tutta... 

Ecco perché non mi meraviglierei a ritrovarmi un boot.efi con la sorpresa ;)

Link to comment
Share on other sites

 Share

×
×
  • Create New...