1
0
mirror of https://github.com/privacyguides/privacyguides.org.git synced 2025-08-04 17:51:23 +00:00

Download Translations from Crowdin (#2054)

This commit is contained in:
Crowdin Bot
2023-02-28 14:22:46 -06:00
committed by Jonah Aragon
parent 4c8cd3f295
commit 1ac4dd75c7
1733 changed files with 199297 additions and 170 deletions

View File

@@ -0,0 +1,135 @@
---
title: Panoramica Android
icon: fontawesome/brands/android
---
Android è un sistema operativo sicuro, dotato di [sandboxing delle app](https://source.android.com/security/app-sandbox), [Verified Boot](https://source.android.com/security/verifiedboot) (AVB) e di un robusto sistema di controllo delle [autorizzazioni](https://developer.android.com/guide/topics/permissions/overview).
## Scegliere una distribuzione di Android
Quando acquisti un telefono Android, il sistema operativo predefinito del dispositivo è spesso dotato di un'integrazione invasiva con applicazioni e servizi che non fanno parte di [Android Open-Source Project](https://source.android.com/). Un esempio è Google Play Services, che ha privilegi irrevocabili di accesso ai file, alla memoria dei contatti, ai registri delle chiamate, ai messaggi SMS, alla posizione, alla fotocamera, al microfono, agli identificatori hardware e così via. Queste applicazioni e servizi aumentano la superficie di attacco del dispositivo e sono all'origine di vari problemi di privacy con Android.
Questo problema potrebbe essere risolto utilizzando una distribuzione modificata di Android che non preveda un'integrazione così invasiva. Purtroppo, molte distribuzioni di Android personalizzate spesso violano il modello di sicurezza di Android, non supportando funzioni di sicurezza critiche come AVB, protezione rollback, aggiornamenti del firmware e così via. Alcune distribuzioni forniscono anche build [`userdebug`](https://source.android.com/setup/build/building#choose-a-target) che espongono root tramite [ADB](https://developer.android.com/studio/command-line/adb) e richiedono politiche SELinux [più permissive](https://github.com/LineageOS/android_system_sepolicy/search?q=userdebug&type=code) per ospitare le funzionalità di debug, con conseguente ulteriore aumento della superficie di attacco e indebolimento del modello di sicurezza.
Idealmente, quando si sceglie una distribuzione modificata di Android, bisogna assicurarsi che rispetti il modello di sicurezza Android. Come minimo, la distribuzione dovrebbe avere build di produzione, supporto per AVB, protezione dal rollback, aggiornamenti tempestivi del firmware e del sistema operativo e SELinux in [modalità enforcing](https://source.android.com/security/selinux/concepts#enforcement_levels). Tutte le distribuzioni di Android da noi consigliate soddisfano questi criteri.
[Le nostre raccomandazioni per il sistema Android :material-arrow-right-drop-circle:](../android.md ""){.md-button}
## Evitare il rooting
Il [rooting](https://it.wikipedia.org/wiki/Rooting) dei telefoni Android può diminuire notevolmente la sicurezza in quanto indebolisce nel complesso il [modello di sicurezza di Android](https://it.wikipedia.org/wiki/Android#Privacy_e_sicurezza). Questo può ridurre la privacy nel caso in cui si verifichi un exploit favorito dalla riduzione della sicurezza. I metodi di rooting più comuni prevedono la manomissione diretta della partizione di avvio, rendendo impossibile l'esecuzione di un Verified Boot. Le applicazioni che richiedono il root modificheranno anche la partizione di sistema, il che significa che Verified Boot dovrà rimanere disabilitato. L'esposizione di root direttamente nell'interfaccia utente aumenta inoltre la [superficie di attacco](https://it.wikipedia.org/wiki/Superficie_di_attacco) del dispositivo e può favorire [l'escalation dei privilegi](https://it.wikipedia.org/wiki/Privilege_escalation) e l'aggiramento delle politiche di SELinux.
Gli adblocker che modificano il [file hosts](https://it.wikipedia.org/wiki/Hosts) (AdAway) e i firewall (AFWall+) che richiedono l'accesso root in modo persistente sono pericolosi e non dovrebbero essere utilizzati. Inoltre, non sono il modo corretto per risolvere i loro scopi. Se vuoi bloccare le pubblicità suggeriamo invece l'uso di [DNS](../dns.md) criptati o di [VPN](../vpn.md) con questa funzione. RethinkDNS, TrackerControl e AdAway in modalità non-root occuperanno lo slot VPN (utilizzando un loopback VPN locale) impedendovi di utilizzare servizi di miglioramento della privacy come Orbot o un vero server VPN.
AFWall+ funziona in base all'approccio del [filtraggio dei pacchetti](https://it.wikipedia.org/wiki/Firewall#Filtraggio_dei_pacchetti/contenuti) e può essere bypassato in alcune situazioni.
Non crediamo che i sacrifici in termini di sicurezza fatti con il rooting di un telefono valgano i discutibili vantaggi per la di privacy di queste applicazioni.
## Verified Boot
Il [Verified Boot](https://source.android.com/security/verifiedboot) (avvio verificato) è una parte importante del modello di sicurezza di Android. Fornisce protezione contro gli attacchi [evil maid](https://en.wikipedia.org/wiki/Evil_maid_attack), la persistenza del malware e garantisce che gli aggiornamenti di sicurezza non possano essere declassati con la protezione da [rollback](https://source.android.com/security/verifiedboot/verified-boot#rollback-protection).
A partire da Android 10 si è passati dalla crittografia dell'intero disco alla più flessibile [crittografia basata sui file](https://source.android.com/security/encryption/file-based). I dati vengono crittografati utilizzando chiavi di crittografia uniche, mentre i file del sistema operativo vengono lasciati in chiaro.
Il Verified Boot garantisce l'integrità dei file del sistema operativo, impedendo così a un avversario con accesso fisico di manomettere o installare malware sul dispositivo. Nel caso improbabile che il malware sia in grado di sfruttare altre parti del sistema e ottenere un accesso privilegiato superiore, Verified Boot impedisce e ripristina le modifiche alla partizione di sistema al riavvio del dispositivo.
Sfortunatamente, gli OEM sono obbligati a supportare il Verified Boot solo sulla loro distribuzione stock di Android. Solo alcuni OEM, come Google, supportano la registrazione personalizzata della chiave AVB sui loro dispositivi. Inoltre, alcuni derivati di AOSP come LineageOS o /e/ OS non supportano il Verified Boot anche su hardware con supporto per il Verified Boot per sistemi operativi di terze parti. Si consiglia di verificare il supporto **prima** di acquistare un nuovo dispositivo. I derivati di AOSP che non supportano il Verified Boot **non** sono consigliati.
Molti OEM hanno anche implementazioni non funzionanti del Verified Boot di cui bisogna essere consapevoli al di là del loro marketing. Ad esempio, i Fairphone 3 e 4 non sono sicuri per impostazione predefinita, poiché il bootloader stock di [si affida alla chiave di firma AVB pubblica](https://forum.fairphone.com/t/bootloader-avb-keys-used-in-roms-for-fairphone-3-4/83448/11). Ciò invalida l'avvio verificato su un dispositivo Fairphone stock, in quanto il sistema avvierà sistemi operativi Android alternativi come (ad esempio /e/) [senza alcun avviso](https://source.android.com/security/verifiedboot/boot-flow#locked-devices-with-custom-root-of-trust) sull'utilizzo del sistema operativo modificato.
## Aggiornamenti del firmware
Gli aggiornamenti del firmware sono fondamentali per mantenere la sicurezza e senza di essi il dispositivo non può essere sicuro. Gli OEM stipulano accordi di supporto con i loro partner per fornire i componenti closed-source per un periodo di supporto limitato. Questi sono riportati mesilmente in [Android Security Bulletins](https://source.android.com/security/bulletin) (bollettini di sicurezza di Android).
Poiché i componenti del telefono, come il processore e le tecnologie radio, si basano su componenti closed-source, gli aggiornamenti devono essere forniti dai rispettivi produttori. Pertanto, è importante acquistare un dispositivo all'interno di un ciclo di assistenza attivo. [Qualcomm](https://www.qualcomm.com/news/releases/2020/12/16/qualcomm-and-google-announce-collaboration-extend-android-os-support-and) e [Samsung](https://news.samsung.com/us/samsung-galaxy-security-extending-updates-knox/) supportano i loro dispositivi per 4 anni, mentre i prodotti più economici hanno spesso cicli di supporto più brevi. Con l'introduzione di [Pixel 6](https://support.google.com/pixelphone/answer/4457705), Google produce ora il proprio SoC e fornirà un supporto di almeno 5 anni.
I dispositivi EOL che non sono più supportati dal produttore del SoC non possono ricevere aggiornamenti del firmware dai fornitori OEM o dai distributori Android after market. Ciò significa che i problemi di sicurezza di questi dispositivi non saranno risolti.
Fairphone, ad esempio, commercializza i propri dispositivi con 6 anni di assistenza. Tuttavia, il SoC (Qualcomm Snapdragon 750G sul Fairphone 4) ha una data di scadenza molto più breve. Ciò significa che gli aggiornamenti di sicurezza del firmware di Qualcomm per il Fairphone 4 termineranno nel settembre 2023, indipendentemente dal fatto che Fairphone continui a rilasciare aggiornamenti di sicurezza del software.
## Versioni di Android
È importante non utilizzare una versione di Android a [fine vita](https://endoflife.date/android). Le nuove versioni di Android non ricevono solo aggiornamenti di sicurezza per il sistema operativo, ma anche importanti aggiornamenti per migliorare la privacy. Ad esempio, [prima di Android 10](https://developer.android.com/about/versions/10/privacy/changes), qualsiasi app con l'autorizzazione [`READ_PHONE_STATE`](https://developer.android.com/reference/android/Manifest.permission#READ_PHONE_STATE) poteva accedere a numeri di serie sensibili e unici del telefono, come [IMEI](https://it.wikipedia.org/wiki/International_Mobile_Equipment_Identity), [MEID](https://en.wikipedia.org/wiki/Mobile_equipment_identifier) e [IMSI](https://it.wikipedia.org/wiki/IMSI) della carta SIM, mentre ora devono essere app di sistema per farlo. Le applicazioni di sistema sono fornite solo dagli OEM o dalla distribuzione di Android.
## Autorizzazioni di Android
[Le autorizzazioni su Android](https://developer.android.com/guide/topics/permissions/overview) consentono di controllare ciò a cui le applicazioni hanno accesso. Google apporta regolarmente [miglioramenti](https://developer.android.com/about/versions/11/privacy/permissions) al sistema delle autorizzazioni in ogni nuova versione. Tutte le applicazioni installate sono rigorosamente [confinate in una sandbox](https://source.android.com/security/app-sandbox), pertanto non è necessario installare alcuna applicazione come antivirus. Uno smartphone con l'ultima versione di Android sarà sempre più sicuro di un vecchio smartphone con un antivirus a pagamento. È meglio non pagare il software antivirus e risparmiare per acquistare un nuovo smartphone come il Google Pixel.
Se volete eseguire un'applicazione di cui non siete sicuri, prendete in considerazione l'utilizzo di un profilo utente o di lavoro.
## Accesso ai media
Molte applicazioni consentono di "condividere" un file per il caricamento dei media. Se desideri, ad esempio, caricare una foto su Twitter, non concedere a Twitter l'accesso a "media e foto", perché in questo modo avrà accesso a tutte le immagini. Invece, apri il gestore di file (documentsUI), tieni premuta l'immagine, quindi condividila con Twitter.
## Profili utente
I profili utente multipli si trovano in **Impostazioni****Sistema****Utenti multipli** e sono il modo più semplice per isolare in Android.
Con i profili utente, è possibile imporre restrizioni a un profilo specifico, come ad esempio: effettuare chiamate, utilizzare SMS o installare applicazioni sul dispositivo. Ogni profilo è crittografato con la propria chiave di crittografia e non può accedere ai dati di altri profili. Anche il proprietario del dispositivo non può visualizzare i dati di altri profili senza conoscere la loro password. I profili utente multipli sono un metodo di isolamento più sicuro.
## Profilo di lavoro
I [Profili di lavoro](https://support.google.com/work/android/answer/6191949) sono un altro modo per isolare le singole app e può essere più comodo dei profili utente separati.
Per creare un profilo di lavoro senza un MDM aziendale è necessaria un'applicazione come **controllore del dispositivo**, come [Shelter](#recommended-apps), a meno che tu non utilizzi un sistema operativo Android modificato che ne include uno.
Il profilo di lavoro dipende da un controllore del dispositivo per funzionare. Funzionalità come *File Shuttle* e *blocco della ricerca dei contatti* o qualsiasi tipo di funzionalità di isolamento devono essere implementate dal controllore. È inoltre necessario fidarsi completamente dell'app di controllo del dispositivo, che ha pieno accesso ai dati dell'utente all'interno del profilo di lavoro.
Questo metodo è generalmente meno sicuro di un profilo utente secondario; tuttavia, consente di eseguire contemporaneamente le applicazioni nel profilo di lavoro e in quello personale.
## Killswitch per VPN
Android 7 e successivi supporta un killswitch per VPN ed è disponibile senza la necessità di installare applicazioni di terze parti. Questa funzione può prevenire la fuga di dati in caso di disconnessione della VPN. Si trova in :gear: **Impostazioni****Rete e Internet****VPN** → :gear: → **Blocca connessioni senza VPN**.
## Interruttori globali
I dispositivi Android moderni dispongono di interruttori globali per disattivare il Bluetooth e i servizi di localizzazione. Android 12 ha introdotto gli interruttori per la fotocamera e il microfono. Quando non vengono utilizzate, si consiglia di disabilitare queste funzioni. Le applicazioni non possono utilizzare le funzioni disabilitate (anche se hanno ottenuto un'autorizzazione individuale) finché non vengono riattivate.
## Google
Se utilizzi un dispositivo con i servizi di Google, sia con il sistema operativo di serie sia con un sistema operativo che mette in sicurezza i Google Play Services, come GrapheneOS, è possibile apportare una serie di modifiche aggiuntive per migliorare la privacy. Si consiglia comunque di evitare del tutto i servizi di Google o di limitare i servizi di Google Play a un profilo specifico utente o di lavoro, combinando un controller di dispositivo come *Shelter* con Sandboxed Google Play di GrapheneOS.
### Programma di protezione avanzata
Se disponi di un account Google, consigliamo di iscriversi al https://landing.google.com/intl/it/advancedprotection/programma di protezione avanzata</a>. È disponibile gratuitamente per chiunque possieda due o più chiavi di sicurezza hardware con supporto a [FIDO](../basics/multi-factor-authentication.md#fido-fast-identity-online).
Il programma di protezione avanzata offre un monitoraggio avanzato delle minacce e consente:
- Autenticazione a due fattori più rigorosa; ad esempio, [FIDO](../basics/multi-factor-authentication.md#fido-fast-identity-online) **deve** essere utilizzato e non è consentito l'uso di [SMS OTP](../basics/multi-factor-authentication.md#sms-or-email-mfa), [TOTP](../basics/multi-factor-authentication.md#time-based-one-time-password-totp) e [OAuth](https://it.wikipedia.org/wiki/OAuth)
- Solo Google e le app di terze parti verificate possono accedere ai dati dell'account
- Scansione delle email in arrivo sugli account Gmail per i tentativi di [phishing ](https://en.wikipedia.org/wiki/Phishing#Email_phishing)
- [Scansione sicura del browser](https://www.google.com/chrome/privacy/whitepaper.html#malware) più rigorosa con Google Chrome
- Processo di recupero più rigoroso per gli account con credenziali perdute
Se utilizzi Google Play Services senza sandbox (comuni sui sistemi operativi stock), il programma di protezione avanzata viene fornito anche con [vantaggi aggiuntivi](https://support.google.com/accounts/answer/9764949?hl=it) quali:
- Non permettere l'installazione di app al di fuori del Google Play Store, dell'app store del fornitore del sistema operativo o tramite [`adb`](https://it.wikipedia.org/wiki/Android_Debug_Bridge)
- Scansione automatica obbligatoria del dispositivo con [Play Protect](https://support.google.com/googleplay/answer/2812853?hl=it#zippy=%2Chow-malware-protection-works%2Chow-privacy-alerts-work)
- Avviso sulle applicazioni non verificate
### Aggiornamenti dei servizi di sistema di Google
In passato, gli aggiornamenti di sicurezza di Android dovevano essere forniti dal fornitore del sistema operativo. Android è diventato più modulare a partire da Android 10 e Google può inviare aggiornamenti di sicurezza per **alcuni componenti del sistema** tramite i Play Services privilegiati.
Se disponi di un dispositivo EOL con Android 10 o superiore e non sei in grado di installare uno dei nostri sistemi operativi consigliati sul dispositivo, è probabile che sia meglio attenersi alla distribuzione di Android dell'OEM (rispetto a un sistema operativo non elencato qui, come LineageOS o /e/ OS). Questo ti permetterà di ricevere **alcune** correzioni di sicurezza da parte di Google, senza però violare il modello di sicurezza Android utilizzando un derivato di Android insicuro e aumentando la superficie di attacco. Consigliamo comunque di passare a un dispositivo supportato il prima possibile.
### ID pubblicità
Tutti i dispositivi con Google Play Services installato generano automaticamente un [ID pubblicità](https://support.google.com/googleplay/android-developer/answer/6048248?hl=en) utilizzato per la pubblicità mirata. Disattiva questa funzione per limitare i dati raccolti su di te.
Sulle distribuzioni Android con [Sandboxed Google Play](https://grapheneos.org/usage#sandboxed-google-play), vai su :gear: **Settings****Apps****Sandboxed Google Play****Google Settings****Ads**, e selezionare *Delete advertising ID*.
Sulle distribuzioni di Android con Google Play Services privilegiato (come i sistemi operativi stock), l'impostazione può trovarsi in una delle diverse posizioni. Controlla
- :gear: **Impostazioni****Google****Annunci**
- :gear: **Impostazioni****Privacy****Annunci**
Ti verrà data la possibilità di eliminare l'ID pubblicità o di *rinunciare agli annunci basati sugli interessi*, questo varia tra le distribuzioni OEM di Android. È raccomandato eliminare l'ID pubblicità se viene data la possibilità. In caso contrario, assicurati di disattivare e reimpostare l'ID pubblicità.
### SafetyNet e API Play Integrity
[SafetyNet](https://developer.android.com/training/safetynet/attestation) e le API [Play Integrity](https://developer.android.com/google/play/integrity) sono generalmente utilizzate per [le app bancarie](https://grapheneos.org/usage#banking-apps). Molte applicazioni bancarie funzionano bene in GrapheneOS con i servizi Play in sandbox, ma alcune applicazioni non finanziarie hanno i loro meccanismi anti-manomissione che potrebbero fallire. GrapheneOS supera il controllo `basicIntegrity`, ma non il controllo di certificazione `ctsProfileMatch`. I dispositivi con Android 8 o successivi dispongono di un supporto di attestazione hardware che non può essere aggirato senza chiavi trapelate o gravi vulnerabilità.
Per quanto riguarda Google Wallet, lo sconsigliamo a causa dell'[informativa sulla privacy](https://payments.google.com/payments/apis-secure/get_legal_document?ldo=0&ldt=privacynotice&ldl=en), che prevede l'opt-out se non si desidera che il proprio rating creditizio e i propri dati personali vengano condivisi con i servizi di marketing affiliati.
--8<-- "includes/abbreviations.it.txt"

View File

@@ -0,0 +1,143 @@
---
title: Linux Overview
icon: simple/linux
---
It is often believed that [open-source](https://en.wikipedia.org/wiki/Open-source_software) software is inherently secure because the source code is available. There is an expectation that community verification occurs regularly; however, this isnt always [the case](https://seirdy.one/posts/2022/02/02/floss-security/). It does depend on a number of factors, such as project activity, developer experience, level of rigour applied to [code reviews](https://en.wikipedia.org/wiki/Code_review), and how often attention is given to specific parts of the [codebase](https://en.wikipedia.org/wiki/Codebase) that may go untouched for years.
At the moment, desktop Linux does have some areas that could be better improved when compared to their proprietary counterparts, e.g.:
- A verified boot chain, like Apples [Secure Boot](https://support.apple.com/guide/security/startup-security-utility-secc7b34e5b5/web) (with [Secure Enclave](https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/1/web/1)), Androids [Verified Boot](https://source.android.com/security/verifiedboot), ChromeOS' [Verified boot](https://www.chromium.org/chromium-os/chromiumos-design-docs/security-overview/#verified-boot), or Microsoft Windowss [boot process](https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process) with [TPM](https://docs.microsoft.com/en-us/windows/security/information-protection/tpm/how-windows-uses-the-tpm). These features and hardware technologies can all help prevent persistent tampering by malware or [evil maid attacks](https://en.wikipedia.org/wiki/Evil_Maid_attack)
- A strong sandboxing solution such as that found in [macOS](https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html), [ChromeOS](https://chromium.googlesource.com/chromiumos/docs/+/HEAD/sandboxing.md), and [Android](https://source.android.com/security/app-sandbox). Commonly used Linux sandboxing solutions such as [Flatpak](https://docs.flatpak.org/en/latest/sandbox-permissions.html) and [Firejail](https://firejail.wordpress.com/) still have a long way to go
- Strong [exploit mitigations](https://madaidans-insecurities.github.io/linux.html#exploit-mitigations)
Despite these drawbacks, desktop Linux distributions are great if you want to:
- Avoid telemetry that often comes with proprietary operating systems
- Maintain [software freedom](https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms)
- Have privacy focused systems such as [Whonix](https://www.whonix.org) or [Tails](https://tails.boum.org/)
Our website generally uses the term “Linux” to describe desktop Linux distributions. Other operating systems which also use the Linux kernel such as ChromeOS, Android, and Qubes OS are not discussed here.
[Our Linux Recommendations :material-arrow-right-drop-circle:](../desktop.md ""){.md-button}
## Choosing your distribution
Not all Linux distributions are created equal. While our Linux recommendation page is not meant to be an authoritative source on which distribution you should use, there are a few things you should keep in mind when choosing which distribution to use.
### Release cycle
We highly recommend that you choose distributions which stay close to the stable upstream software releases, often referred to as rolling release distributions. This is because frozen release cycle distributions often dont update package versions and fall behind on security updates.
For frozen distributions such as [Debian](https://www.debian.org/security/faq#handling), package maintainers are expected to backport patches to fix vulnerabilities rather than bump the software to the “next version” released by the upstream developer. Some security fixes [do not](https://arxiv.org/abs/2105.14565) receive a [CVE](https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures) (particularly less popular software) at all and therefore do not make it into the distribution with this patching model. As a result minor security fixes are sometimes held back until the next major release.
We dont believe holding packages back and applying interim patches is a good idea, as it diverges from the way the developer might have intended the software to work. [Richard Brown](https://rootco.de/aboutme/) has a presentation about this:
<div class="yt-embed">
<iframe width="560" height="315" src="https://invidious.privacyguides.net/embed/i8c0mg_mS7U?local=true" title="Regular Releases are Wrong, Roll for your life" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>
### Traditional vs Atomic updates
Traditionally, Linux distributions update by sequentially updating the desired packages. Traditional updates such as those used in Fedora, Arch Linux, and Debian based distributions can be less reliable if an error occurs while updating.
Atomic updating distributions apply updates in full or not at all. Typically, transactional update systems are also atomic.
A transactional update system creates a snapshot that is made before and after an update is applied. If an update fails at any time (perhaps due to a power failure), the update can be easily rolled back to a “last known good state."
The Atomic update method is used for immutable distributions like Silverblue, Tumbleweed, and NixOS and can achieve reliability with this model. [Adam Šamalík](https://twitter.com/adsamalik) provided a presentation on how `rpm-ostree` works with Silverblue:
<div class="yt-embed">
<iframe width="560" height="315" src="https://invidious.privacyguides.net/embed/-hpV5l-gJnQ?local=true" title="Let's try Fedora Silverblue — an immutable desktop OS! - Adam Šamalik" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>
### “Security-focused” distributions
There is often some confusion between “security-focused” distributions and “pentesting” distributions. A quick search for “the most secure Linux distribution” will often give results like Kali Linux, Black Arch and Parrot OS. These distributions are offensive penetration testing distributions that bundle tools for testing other systems. They dont include any “extra security” or defensive mitigations intended for regular use.
### Arch-based distributions
Arch based distributions are not recommended for those new to Linux, (regardless of distribution) as they require regular [system maintenance](https://wiki.archlinux.org/title/System_maintenance). Arch does not have an distribution update mechanism for the underlying software choices. As a result you have to stay aware with current trends and adopt technologies as they supersede older practices on your own.
For a secure system, you are also expected to have sufficient Linux knowledge to properly set up security for their system such as adopting a [mandatory access control](https://en.wikipedia.org/wiki/Mandatory_access_control) system, setting up [kernel module](https://en.wikipedia.org/wiki/Loadable_kernel_module#Security) blacklists, hardening boot parameters, manipulating [sysctl](https://en.wikipedia.org/wiki/Sysctl) parameters, and knowing what components they need such as [Polkit](https://en.wikipedia.org/wiki/Polkit).
Anyone using the [Arch User Repository (AUR)](https://wiki.archlinux.org/title/Arch_User_Repository), **must** be comfortable in auditing PKGBUILDs that they install from that service. AUR packages are community-produced content and are not vetted in any way, and therefore are vulnerable to software supply chain attacks, which has in fact happened [in the past](https://www.bleepingcomputer.com/news/security/malware-found-in-arch-linux-aur-package-repository/). AUR should always be used sparingly and often there is a lot of bad advice on various pages which direct people to blindly use [AUR helpers](https://wiki.archlinux.org/title/AUR_helpers) without sufficient warning. Similar warnings apply to use third-party Personal Package Archives (PPAs) on Debian based distributions or Community Projects (COPR) on Fedora.
If you are experienced with Linux and wish to use an Arch-based distribution, we only recommend mainline Arch Linux, not any of its derivatives. We recommend against these two Arch derivatives specifically:
- **Manjaro**: This distribution holds packages back for 2 weeks to make sure that their own changes dont break, not to make sure that upstream is stable. When AUR packages are used, they are often built against the latest [libraries](https://en.wikipedia.org/wiki/Library_(computing)) from Archs repositories.
- **Garuda**: They use [Chaotic-AUR](https://aur.chaotic.cx/) which automatically and blindly compiles packages from the AUR. There is no verification process to make sure that the AUR packages dont suffer from supply chain attacks.
### Kicksecure
While we strongly recommend against using outdated distributions like Debian, there is a Debian based operating system that has been hardened to be much more secure than typical Linux distributions: [Kicksecure](https://www.kicksecure.com/). Kicksecure, in oversimplified terms, is a set of scripts, configurations, and packages that substantially reduce the attack surface of Debian. It covers a lot of privacy and hardening recommendations by default.
### Linux-libre kernel and “Libre” distributions
We strongly recommend **against** using the Linux-libre kernel, since it [removes security mitigations](https://www.phoronix.com/scan.php?page=news_item&px=GNU-Linux-Libre-5.7-Released) and [suppresses kernel warnings](https://news.ycombinator.com/item?id=29674846) about vulnerable microcode for ideological reasons.
## Consigli generali
### Drive Encryption
Most Linux distributions have an option within its installer for enabling [LUKS](../encryption.md#linux-unified-key-setup) FDE. If this option isnt set at installation time, you will have to backup your data and re-install, as encryption is applied after [disk partitioning](https://en.wikipedia.org/wiki/Disk_partitioning), but before [file systems](https://en.wikipedia.org/wiki/File_system) are formatted. We also suggest securely erasing your storage device:
- [Secure Data Erasure :material-arrow-right-drop-circle:](https://blog.privacyguides.org/2022/05/25/secure-data-erasure/)
### Swap
Consider using [ZRAM](https://wiki.archlinux.org/title/Swap#zram-generator) or [encrypted swap](https://wiki.archlinux.org/title/Dm-crypt/Swap_encryption) instead of unencrypted swap to avoid potential security issues with sensitive data being pushed to [swap space](https://en.wikipedia.org/wiki/Memory_paging). Fedora based distributions [use ZRAM by default](https://fedoraproject.org/wiki/Changes/SwapOnZRAM).
### Wayland
We recommend using a desktop environment that supports the [Wayland](https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)) display protocol as it was developed with security [in mind](https://lwn.net/Articles/589147/). Its predecessor, [X11](https://en.wikipedia.org/wiki/X_Window_System), does not support GUI isolation, allowing all windows to [record screen, log and inject inputs in other windows](https://blog.invisiblethings.org/2011/04/23/linux-security-circus-on-gui-isolation.html), making any attempt at sandboxing futile. While there are options to do nested X11 such as [Xpra](https://en.wikipedia.org/wiki/Xpra) or [Xephyr](https://en.wikipedia.org/wiki/Xephyr), they often come with negative performance consequences and are not convenient to set up and are not preferable over Wayland.
Fortunately, common environments such as [GNOME](https://www.gnome.org), [KDE](https://kde.org), and the window manager [Sway](https://swaywm.org) have support for Wayland. Some distributions like Fedora and Tumbleweed use it by default, and some others may do so in the future as X11 is in [hard maintenance mode](https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Maintenance-Mode-Quickly). If youre using one of those environments it is as easy as selecting the “Wayland” session at the desktop display manager ([GDM](https://en.wikipedia.org/wiki/GNOME_Display_Manager), [SDDM](https://en.wikipedia.org/wiki/Simple_Desktop_Display_Manager)).
We recommend **against** using desktop environments or window managers that do not have Wayland support, such as Cinnamon (default on Linux Mint), Pantheon (default on Elementary OS), MATE, Xfce, and i3.
### Proprietary Firmware (Microcode Updates)
Linux distributions such as those which are [Linux-libre](https://en.wikipedia.org/wiki/Linux-libre) or DIY (Arch Linux) dont come with the proprietary [microcode](https://en.wikipedia.org/wiki/Microcode) updates that often patch vulnerabilities. Some notable examples of these vulnerabilities include [Spectre](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)), [Meltdown](https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)), [SSB](https://en.wikipedia.org/wiki/Speculative_Store_Bypass), [Foreshadow](https://en.wikipedia.org/wiki/Foreshadow), [MDS](https://en.wikipedia.org/wiki/Microarchitectural_Data_Sampling), [SWAPGS](https://en.wikipedia.org/wiki/SWAPGS_(security_vulnerability)), and other [hardware vulnerabilities](https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html).
We **highly recommend** that you install the microcode updates, as your CPU is already running the proprietary microcode from the factory. Fedora and openSUSE both have the microcode updates applied by default.
### Updates
Most Linux distributions will automatically install updates or remind you to do so. It is important to keep your OS up to date so that your software is patched when a vulnerability is found.
Some distributions (particularly those aimed at advanced users) are more barebones and expect you to do things yourself (e.g. Arch or Debian). These will require running the "package manager" (`apt`, `pacman`, `dnf`, etc.) manually in order to receive important security updates.
Additionally, some distributions will not download firmware updates automatically. For that you will need to install [`fwupd`](https://wiki.archlinux.org/title/Fwupd).
## Privacy Tweaks
### MAC Address Randomization
Many desktop Linux distributions (Fedora, openSUSE, etc) will come with [NetworkManager](https://en.wikipedia.org/wiki/NetworkManager), to configure Ethernet and Wi-Fi settings.
It is possible to [randomize](https://fedoramagazine.org/randomize-mac-address-nm/) the [MAC address](https://en.wikipedia.org/wiki/MAC_address) when using NetworkManager. This provides a bit more privacy on Wi-Fi networks as it makes it harder to track specific devices on the network youre connected to. It does [**not**](https://papers.mathyvanhoef.com/wisec2016.pdf) make you anonymous.
We recommend changing the setting to **random** instead of **stable**, as suggested in the [article](https://fedoramagazine.org/randomize-mac-address-nm/).
If you are using [systemd-networkd](https://en.wikipedia.org/wiki/Systemd#Ancillary_components), you will need to set [`MACAddressPolicy=random`](https://www.freedesktop.org/software/systemd/man/systemd.link.html#MACAddressPolicy=) which will enable [RFC 7844 (Anonymity Profiles for DHCP Clients)](https://www.freedesktop.org/software/systemd/man/systemd.network.html#Anonymize=).
There isnt many points in randomizing the MAC address for Ethernet connections as a system administrator can find you by looking at the port you are using on the [network switch](https://en.wikipedia.org/wiki/Network_switch). Randomizing Wi-Fi MAC addresses depends on support from the Wi-Fis firmware.
### Other Identifiers
There are other system identifiers which you may wish to be careful about. You should give this some thought to see if it applies to your [threat model](../basics/threat-modeling.md):
- **Hostnames:** Your system's hostname is shared with the networks you connect to. You should avoid including identifying terms like your name or operating system in your hostname, instead sticking to generic terms or random strings.
- **Usernames:** Similarly, your username is used in a variety of ways across your system. Consider using generic terms like "user" rather than your actual name.
- **Machine ID:**: During installation a unique machine ID is generated and stored on your device. Consider [setting it to a generic ID](https://madaidans-insecurities.github.io/guides/linux-hardening.html#machine-id).
### System Counting
The Fedora Project [counts](https://fedoraproject.org/wiki/Changes/DNF_Better_Counting) how many unique systems access its mirrors by using a [`countme`](https://fedoraproject.org/wiki/Changes/DNF_Better_Counting#Detailed_Description) variable instead of a unique ID. Fedora does this to determine load and provision better servers for updates where necessary.
This [option](https://dnf.readthedocs.io/en/latest/conf_ref.html#options-for-both-main-and-repo) is currently off by default. We recommend adding `countme=false` to `/etc/dnf/dnf.conf` just in case it is enabled in the future. On systems that use `rpm-ostree` such as Silverblue, the countme option is disabled by masking the [rpm-ostree-countme](https://fedoramagazine.org/getting-better-at-counting-rpm-ostree-based-systems/) timer.
openSUSE also uses a [unique ID](https://en.opensuse.org/openSUSE:Statistics) to count systems, which can be disabled by deleting the `/var/lib/zypp/AnonymousUniqueId` file.
--8<-- "includes/abbreviations.it.txt"

View File

@@ -0,0 +1,56 @@
---
title: "Panoramica di Qubes"
icon: pg/qubes-os
---
[**Qubes OS**](../desktop.md#qubes-os) è un sistema operativo che utilizza l'hypervisor [Xen](https://en.wikipedia.org/wiki/Xen) per fornire una forte sicurezza per il desktop computing attraverso macchine virtuali isolate. Ogni macchina virtuale è chiamata *Qube* e si può assegnare a ogni Qube un livello di fiducia in base al suo scopo. Poiché il sistema operativo Qubes garantisce la sicurezza utilizzando l'isolamento e consentendo azioni solo su base individuale, è l'opposto dell'[enumerazione delle minacce](https://www.ranum.com/security/computer_security/editorials/dumb/).
## Come funziona Qubes OS?
Qubes utilizza la [compartimentazione](https://www.qubes-os.org/intro/) per mantenere il sistema sicuro. I Qubes sono creati da modelli, predefiniti per Fedora, Debian e [Whonix](../desktop.md#whonix). Qubes OS consente anche di creare macchine virtuali [monouso](https://www.qubes-os.org/doc/how-to-use-disposables/).
![Architettura Qubes](../assets/img/qubes/qubes-trust-level-architecture.png)
<figcaption>Architettura di Qubes, da "What is Qubes OS Introduction"</figcaption>
Ogni applicazione Qubes ha un [bordo colorato](https://www.qubes-os.org/screenshots/) che può aiutare a tenere traccia della macchina virtuale in cui è in esecuzione. You could, for example, use a specific color for your banking browser, while using a different color for a general untrusted browser.
![Bordo colorato](../assets/img/qubes/r4.0-xfce-three-domains-at-work.png)
<figcaption>Qubes window borders, Credit: Qubes Screenshots</figcaption>
## Perché dovrei usare Qubes?
Qubes OS is useful if your [threat model](../basics/threat-modeling.md) requires strong compartmentalization and security, such as if you think you'll be opening untrusted files from untrusted sources. A typical reason for using Qubes OS is to open documents from unknown sources.
Qubes OS utilizes [Dom0](https://wiki.xenproject.org/wiki/Dom0) Xen VM (i.e., an "AdminVM") for controlling other guest VMs or Qubes on the host OS. Other VMs display individual application windows within Dom0's desktop environment. It allows you to color code windows based on trust levels and run apps that can interact with each other with very granular control.
### Copiare e incollare il testo
Puoi [copiare e incollare il testo](https://www.qubes-os.org/doc/how-to-copy-and-paste-text/) utilizzando `qvm-copy-to-vm` o le istruzioni seguenti:
1. Premi **Ctrl+C** per comunicare alla macchina virtuale in cui ti trovi che vuoi copiare qualcosa.
2. Premi **Ctrl+Shift+C** per comunicare alla macchina virtuale di rendere disponibile questo buffer negli appunti globali.
3. Premi **Ctrl+Shift+V** nella macchina virtuale di destinazione per rendere disponibili gli appunti globali.
4. Premi **Ctrl+V** nella macchina virtuale di destinazione per incollare il contenuto nel buffer.
### Scambio di file
Per copiare e incollare file e directory (cartelle) da una macchina virtuale all'altra, si può usare l'opzione **Copy to Other AppVM...** o **Move to Other AppVM...**. La differenza è che l'opzione **Move** elimina il file originale. Either option will protect your clipboard from being leaked to any other Qubes. This is more secure than air-gapped file transfer because an air-gapped computer will still be forced to parse partitions or file systems. That is not required with the inter-qube copy system.
??? info "AppVMs or qubes do not have their own file systems"
You can [copy and move files](https://www.qubes-os.org/doc/how-to-copy-and-move-files/) between Qubes. When doing so the changes aren't immediately made and can be easily undone in case of an accident.
### Inter-VM Interactions
The [qrexec framework](https://www.qubes-os.org/doc/qrexec/) is a core part of Qubes which allows virtual machine communication between domains. It is built on top of the Xen library *vchan*, which facilitates [isolation through policies](https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/).
## Risorse aggiuntive
Per ulteriori informazioni si consiglia di consultare le ampie pagine di documentazione di Qubes OS presenti sul [sito web di Qubes OS](https://www.qubes-os.org/doc/). Le copie offline possono essere scaricate dal [repository della documentazione](https://github.com/QubesOS/qubes-doc) di Qubes OS.
- Open Technology Fund: [*Arguably the world's most secure operating system (Probabilmente il sistema operativo più sicuro al mondo)*](https://www.opentech.fund/news/qubes-os-arguably-the-worlds-most-secure-operating-system-motherboard/)
- J. Rutkowska: [*Software compartmentalization vs. physical separation (Compartimentazione del software vs. separazione fisica)*](https://invisiblethingslab.com/resources/2014/Software_compartmentalization_vs_physical_separation.pdf)
- J. Rutkowska: [*Partitioning my digital life into security domains (Suddividere la mia vita digitale in domini di sicurezza)*](https://blog.invisiblethings.org/2011/03/13/partitioning-my-digital-life-into.html)
- Qubes OS: [*Articoli correlati*](https://www.qubes-os.org/news/categories/#articles)
--8<-- "includes/abbreviations.it.txt"