Attachment: publickey - logan@threatmodel.io.asc.pgp
Description: application/pgp-key

Would you be willing to share the URL here? If not, could you message me privately? I'm definitely interested in reading it.

-Logan

On 5/11/20 11:58 AM, Mark Fernandes wrote:
On Monday, 11 May 2020 12:08:22 UTC+1, unman wrote:
 
.... Depending on your machine you
may be able to find ways to do this, by installing a kill switch, or by
BIOS configuration.
You may find that your BIOS allows you to disable certain devices pre
boot, and this may enable you to switch between active disks. 
....

I'm by no means an expert on Qubes or this particular issue. However, I am in the midst of writing a Wikibooks book on cost-effective end-user security that has a section about this. My thoughts in the book are more like RFCs (requests for comments) rather than definitive ideas (my hope is that other people will further develop, revise, and correct them, as applicable). Please take that into account when reading them. The section is shown below.


Qubes OS 4.0.3 side-by-side with other operating systems

Qubes OS 4.0.3 is documented as not coping well with software that specifically benefits from 3D-optimised hardware. Since a user may well want to use such optimisation, the best way to use such optimisation on the same machine might be to do something like, or the same as, the following:


  1. Install a Linux operating system, with good security but still with the capacity for being able to utilise 3D-optimised hardware, on an SSD external drive, such that this other operating system is not run over Qubes, but instead run separate to Qubes.

  2. When wanting to use this other Linux OS, disable the internal drive (containing Qubes) in either:

    1. the BIOS,   

       OR IF WISHING TO BE MORE SECURE,

    1. both the BIOS 

as well as by physically disconnecting the internal drive

(this latter option might be a good idea to do 

because malware in a BIOS's firmware 

can still connect to BIOS-disabled drives).

  1. Boot off the SSD to run this other Linux.

  2. After using the non-Qubes installation, because of the possibility of malware being introduced into the BIOS firmware by the non-Qubes installation, optionally flash the BIOS's firmware to ensure better the Qubes installation isn’t compromised through firmware malware when you next use Qubes.


By following the above steps, and choosing the most secure options in the steps, because of:

  • the disabling of the internal drive via the BIOS,

  • the physical disconnection of the drive containing the Qubes installation,   and

  • the flashing of the BIOS firmware before the ‘reconnection’ of the Qubes installation,

any such other OS should not be able to access or even ‘touch’ the Qubes OS installation, thereby hopefully safeguarding the Qubes installation from attacks conducted through the other presumably-less-secure OS.





Kind regards,


Mark Fernandes
--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/be02e5ea-f7a5-473b-9fd0-1d06a9223f0c%40googlegroups.com.


--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e6af715a-fe00-46ec-ddde-24748076ad2b%40threatmodel.io.

Attachment: publickey - logan@threatmodel.io.asc.pgp
Description: application/pgp-key

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to