3806ecf338
Those are redundant, and yaml parser strips them in fact. By removing them, loading and saving yaml file without any change indeed produce the same output. This is useful for prepare_for_translation.py script (which adds lang and ref tags) - to produce only change that indeed was made.
3.6 KiB
| lang | layout | permalink | redirect_from | ref | title | |||
|---|---|---|---|---|---|---|---|---|
| en | doc | /doc/anti-evil-maid/ |
|
164 | Anti Evil Maid (AEM) |
Background
Please read this blog article.
Requirements
The current package requires a TPM 1.2 interface and a working Intel TXT engine. If you cleaned your Intel Management Engine with e.g. me_cleaner while installing CoreBoot then you are out of luck. For now you have to choose between cleaning your BIOS and deploying Anti Evil Maid.
Installing
In Dom0 install anti-evil-maid:
sudo qubes-dom0-update anti-evil-maid
For more information, see the qubes-antievilmaid repository, which includes a README.
Security Considerations
Qubes security guidelines dictate that USB devices should never be attached directly to dom0, since this can result in the entire system being compromised. However, in its default configuration, installing and using AEM requires attaching a USB drive (i.e., mass storage device) directly to dom0. (The other option is to install AEM to an internal disk. However, this carries significant security implications, as explained here.) This presents us with a classic security trade-off: each Qubes user must make a choice between protecting dom0 from a potentially malicious USB drive, on the one hand, and protecting the system from Evil Maid attacks, on the other hand. Given the practical feasibility of attacks like BadUSB and revelations regarding pervasive government hardware backdoors, this is no longer a straightforward decision. New, factory-sealed USB drives cannot simply be assumed to be "clean" (e.g., to have non-malicious microcontroller firmware). Therefore, it is up to each individual Qubes user to evaluate the relative risk of each attack vector against his or her security model.
For example, a user who frequently travels with a Qubes laptop holding sensitive data may be at a much higher risk of Evil Maid attacks than a home user with a stationary Qubes desktop. If the frequent traveler judges her risk of an Evil Maid attack to be higher than the risk of a malicious USB device, she might reasonably opt to install and use AEM. On the other hand, the home user might deem the probability of an Evil Maid attack occurring in her own home to be so low that there is a higher probability that any USB drive she purchases is already compromised, in which case she might reasonably opt never to attach any USB devices directly to dom0. (In either case, users can--and should--secure dom0 against further USB-related attacks through the use of a USB VM.)
For more information, please see this discussion thread.
Known issues
- USB 3.0 isn't supported yet
- AEM is not compatible with having an SSD cache