Qual è la soluzione alternativa 'ptrace_scope' per i programmi Wine e ci sono dei rischi?

Per eseguire determinati programmi Windows in WINE è necessario questa soluzione alternativa:

echo 0|sudo tee /proc/sys/kernel/yama/ptrace_scope

Secondo i siti Web di supporto, ciò è dovuto a un bug nel kernel Ubuntu che impedisce a ptrace e WINE di giocare bene insieme.

Usando il comando sopra hai impostato ptrace su 0 che secondo la ricerca che ho fatto (non chiedermi quali siti Web, mi sembrano molti), ptrace ha a che fare con le interazioni tra i programmi. L'impostazione 0 è più permissiva dell'1.

Devo presumere che ci fosse una buona ragione per cui Ubuntu voleva ptrace = 1, quindi questo mi riporta alla forma breve della domanda.

Ci sono dei rischi associati all'impostazione di ptrace = 0. Bassa sicurezza? problemi di debug? altri a cui non ho pensato ???

PS per chiunque legga questo che si chiede quale sia la causa del bug, i programmi di Windows non si apriranno affatto, nel Monitor di sistema vedrai molte istanze del programma che tentano di aprirsi e poi alla fine si chiuderanno tutti e se esegui il programma per il terminale verrà visualizzato un errore che indica che è stato raggiunto il numero massimo di istanze del programma.

Risposta breve: nessun pericolo pratico ancora, ma continua a leggere per un modo migliore ...

Cos'è questa cosa alla moda ?

questo è dovuto a un bug nel kernel Ubuntu che impedisce a ptrace e WINE di giocare bene insieme.

• No, la protezione ptrace è una misura di sicurezza del kernel deliberata introdotta per la prima volta in Ubuntu 10.10. Non è un bug , quindi non verrà "risolto".

• In termini semplici, il ptrace_scopevalore predefinito 1impedisce a un processo di esaminare e modificare un altro processo a meno che il secondo processo (padre) non abbia avviato il secondo processo (figlio).

• Ciò può causare problemi con alcuni programmi in Wine a causa del modo in cui wineserverfornisce "Servizi Windows" a questi programmi.

Quali sono i rischi nella creazione ptrace_scopedi 0?

• Ciò ripristina il vecchio comportamento in cui un processo può "rintracciare" un altro processo, anche se non esiste una relazione padre-figlio.

• In teoria, un malware può usarlo per danneggiare te / il tuo computer; ad es. può collegarsi a Firefox e registrare tutti i tuoi URL / password, ecc. In pratica questo è estremamente improbabile a meno che tu non installi ciechi binari da siti casuali, ecc.

• Per quanto riguarda il debug, le 0impostazioni sono in effetti necessarie per gdb, straceecc., Per essere collegate ai non figli a meno che non vengano eseguite con privilegi elevati (sudo).

Quali sono i problemi con la soluzione alternativa?

• La soluzione alternativa è alquanto problematica perché ptrace_scopeè un valore globale e, sebbene sia impostato su 0, tutti i processi sul sistema sono esenti dalla restrizione non figlio.
• Se si utilizza la soluzione alternativa, inserirla in un semplice script bash che lo abilita, esegue il programma Windows e quindi disabilita (imposta su 1) all'uscita.
  • NON rendere ptrace_scopescrivibile in tutto il mondo (666) come raccomandato dal post del forum - questo è un enorme rischio per la sicurezza perché ora qualsiasi processo può cambiarlo a piacimento!

C'è una soluzione migliore?

• Una soluzione migliore, più sicura e che non richiede la modifica ripetitiva di ptrace_scope, è quella di garantire le capacità ptrace di Wineserver .

  • In un terminale:

    sudo apt-get install libcap2-bin 
    sudo setcap cap_sys_ptrace = eip / usr / bin / wineserver
    sudo setcap cap_sys_ptrace = eip / usr / bin / wine-preloader
    

  • Ciò esenta i file binari di wine server e wine-preloader dalla restrizione ptrace non figlio e consente loro di affrontare qualsiasi processo.

  • Deve essere eseguito una sola volta ed è più sicuro perché questi file binari provengono generalmente da una fonte attendibile: i repository ufficiali o il Wine PPA ufficiale, quindi non saranno malware.

Se stai usando Crossover

Installa libcap2:

sudo apt-get install libcap2-bin;

Quindi, aggiungi un'eccezione per Crossover:

sudo setcap cap_sys_ptrace = eip / opt / cxoffice / bin / wineserver;
sudo setcap cap_sys_ptrace = eip / opt / cxoffice / bin / wine-preloader;

Infine, aggiungi le sue librerie a ld.so.conf (o otterrai "errore durante il caricamento delle librerie condivise: libwine.so.1: impossibile aprire il file oggetto condiviso: nessun file o directory"):

echo / opt / cxoffice / lib / | sudo tee /etc/ld.so.conf.d/crossover.conf
sudo / sbin / ldconfig

In ubuntuforums.org ho ricevuto una risposta con il seguente link

https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection

ecco la pasta dal link (con la mia enfasi aggiunta)

Man mano che Linux cresce in popolarità, diventerà un bersaglio crescente per il malware. Una debolezza particolarmente preoccupante delle interfacce di processo di Linux è che un singolo utente è in grado di esaminare la memoria e lo stato di esecuzione di qualsiasi suo processo. Ad esempio, se un'applicazione (ad es. Firefox) fosse compromessa, sarebbe possibile che un utente malintenzionato si collegasse ad altri processi in esecuzione (ad es. Agente gpg) per estrarre ulteriori credenziali e continuare a espandere l'ambito del loro attacco.

Questo non è un problema teorico. Il dirottamento della sessione SSH e persino l'iniezione di codice arbitrario sono completamente possibili se ptrace è consentito normalmente .

Per una soluzione, alcune applicazioni usano prctl () per impedire specificatamente tale allegato ptrace (ad esempio ssh-agent). Una soluzione più generale è consentire solo ptrace direttamente da un genitore a un processo figlio (ovvero gdb diretto e lo strace funzionano ancora) o come utente root (ovvero pID BIN di gdb e PID strace -p funzionano ancora come root).

Questo comportamento è controllato tramite il valore sysctl / proc / sys / kernel / yama / ptrace_scope. L'impostazione predefinita è "1" per bloccare ptrace non figlio. Un valore "0" ripristina il comportamento precedente più permissivo, che può essere più appropriato per alcuni sistemi e server di sviluppo con solo account amministratore. L'uso di "sudo" può anche concedere autorizzazioni ptrace temporaneamente tramite la funzionalità CAP_SYS_PTRACE, sebbene questo metodo consenta lo ptrace di qualsiasi processo.

Quindi immagino che la risposta breve sarebbe che è meno sicuro, ma la probabile cappa di un personal computer che subisce questo tipo di attacchi sarebbe piuttosto sottile.

AGGIORNAMENTO Le istruzioni precedenti:

sudo setcap cap_sys_ptrace=eip /opt/cxoffice/bin/wineserver;
sudo setcap cap_sys_ptrace=eip /opt/cxoffice/bin/wine-preloader;

non funziona dal 15/09/2018 su Ubuntu 18.04.1 e PlayOnLinux v.4.2.12 utilizzando l'ultima versione stabile Wine che è v.3.0.1 libcap2 già installata.

Il messaggio di errore nel Terminale Gnome è il seguente:

Failed to set capabilities on file `/usr/bin/wineserver' (Invalid argument)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file

Non sono sicuro di cosa significhi ..... ma ho pensato che l'avrei messo lì per qualcuno da interpretare e magari avere una nuova soluzione praticabile.

Grazie.