Re: [qubes-users] Grub with encrypted boot
Can you elaborate on this a bit please? Or point at some manual that could help get started with th topic? While the concept sounds familiar I don't have enough experience to build a secure boot environment from scratch - and that's what needs to be done in case of Qubes. On Wednesday, May 6, 2020 at 9:16:54 AM UTC+2, dhorf-hfr...@hashmail.org wrote: > > On Wed, May 06, 2020 at 06:21:00AM +, lamboicarus via qubes-users > wrote: > > I am wondering if anyone knows how I might install grub for use with > > an encrypted boot partition, or no boot partition at all. I have > > recently decided to use btrfs, and I have grub working fine. The > > grub2-efi config from the qubes-dom0-unstable repo is working fine, > > but it's very complex. Reading about grub on the arch-wiki, it says > > boot security is a very complex topic. > > just encrypting your /boot but keeping an unencrypted grub > around that opens that /boot is not increasing your security > in any meaningful way. it just adds a pile of fragility. > > for actual cryptographic boot security, you need a "verified" > and/or "measured" boot setup. > > since you mentioned "efi", i would recommend an efi-heads hybrid. > deploy a linux kernel with _internal_ initrd (!) as efi-verified > boot payload. this way you have to do the efi-signing "just once", > and from that linux kernel you can open your encrypted /boot > in the "natural linux ways". > > if your "bios" takes measurements during boot, do tpmtotp (or similar) > from the first stage linux (before unlocking your /boot) you dont even > have to do any modifications to the payloads inside /boot ... > so no resigning/resealing on every payload-xen/kernel update either! > > this setup does not involve grub at all. this is intentional. > > > > -- 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/8afd7aef-5470-4ab3-b83b-2dccd1246414%40googlegroups.com.
[qubes-users] Re: Mounting directories across VMs (losetup/block device solution for directories)?
I don't think you can achieve this by block device sharing unless you spread your directory structure across block devices exactly in a way you are going to share it with VMs - and even in that case you'll not be able to share with VM and sync with Dropbox at the same time (you didn't specify if that's required). I suggest you explore the options of network shares using NFS/SAMBA/FTP/WebDAV/etc - together with passing just that network port to the target VM this can be a good solution. On Wednesday, February 26, 2020 at 10:23:41 PM UTC+1, Johannes Graumann wrote: > > Hi, > I'm experimenting with creating a sys-dropbox vm that syncs with my > dropbox account. I would love to be able to then mount defined > subdirectories of the synced path to other vms (losetop/qvm-block- > style, which only works for files). > Is this possible? Where to find pointers? > > Sincerely, Joh > > -- 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/3a9ee4f4-0795-45b4-bfb9-4b674483a010%40googlegroups.com.
[qubes-users] Re: Making a HVM VM start in headless mode
The following settings work for me: 1. Set "debug" to "False" in qvm-prefs 2. Set "gui" to "False" and "gui-emulated" to "False" The only problem is qubes (or xen) keeps cashed info on whether to show emulated console. Sometimes the settings work immediately, sometimes after a reboot, sometimes I need to delete old vm files laying abound. On Sunday, January 12, 2020 at 4:28:30 AM UTC+1, tetra...@danwin1210.me wrote: > > When I create a HVM VM, by default I have the console window of the VM > open all the time when it is running. > > Sys-net is HVM by default but there is no console window. > > How do I set this up for other HVM VMs? > -- 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/e2159ed7-4fb1-470d-8076-0ce40e0d9995%40googlegroups.com.
Re: [qubes-users] Re: Receive-only email VM
As long as your dedicated Thunderbird VM has internet connection (which it needs to receive email) an attacker can get any data out of it using Thunderbird exploits, whether you set up outgoing mail server or not. Kind regards, Alex On 8/7/19 4:18 AM, V C wrote: Couldn't you just use a dedicated VM and thunderbird, don't set up outbound in thunderbird? On Tuesday, August 6, 2019 at 1:11:32 AM UTC-5, alex@gmail.com wrote: Some time ago there was a post on reddit (https://www.reddit.com/r/Qubes/comments/9q76f2/splitmail_setup/) that described setting up an offline mail vm. Just kill the "send" part there and you'll get a mail black hole that receivs but never sends. Seems like this is more or less what you want. On Tuesday, August 6, 2019 at 5:06:54 AM UTC+3, redd...@vfemail.net wrote: In Qubes, is it possible to set up a VM that can receive email, but not send information out, via email or otherwise? The motivation is: Many online accounts rely on an email address to reset passwords. However, the VM that handles inbound emails, processes a lot of untrusted input. If the VM gets compromised by an attacker, the attacker can then send password reset emails and read them. So to defend against this, I want to prevent the compromised VM from communicating out the contents of these password reset e -- 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/5bfb314f-2c22-9322-cb18-c199a1b862e6%40gmail.com.
[qubes-users] Re: Receive-only email VM
Some time ago there was a post on reddit ( https://www.reddit.com/r/Qubes/comments/9q76f2/splitmail_setup/) that described setting up an offline mail vm. Just kill the "send" part there and you'll get a mail black hole that receivs but never sends. Seems like this is more or less what you want. On Tuesday, August 6, 2019 at 5:06:54 AM UTC+3, redd...@vfemail.net wrote: > > In Qubes, is it possible to set up a VM that can receive email, but not > send information out, via email or otherwise? > > The motivation is: Many online accounts rely on an email address to reset > passwords. However, the VM that handles inbound emails, processes a lot of > untrusted input. If the VM gets compromised by an attacker, the attacker > can then send password reset emails and read them. So to defend against > this, I want to prevent the compromised VM from communicating out the > contents of these password reset emails. > > Specifically: > 1. Assume the VM is compromised (can't rely on in-VM enforcement > mechanisms). > 2. Assume the email provider is not compromised > > To further illustrate the problem, here are example setups and why they > don't work: > > Setup 1: Use qubes firewall to restrict to the email provider's server and > IMAP port. Block UDP requests using qvm-firewall. > Why it doesn't work: Attacker can create an account on the same email > provider and connect to their account (the firewall rules will not prevent > this). They can then sync emails containing any data, to their account. > > Setup 2: Like Setup 1, but use POP3. > Why it doesn't work: Attacker creates account at provider, transmits data > via POP3 delete operations. > > Does anyone have a email setup with this inbound-only property, ideally > that does not require running their own email server? > > Thank you. > > > - > This free account was provided by VFEmail.net - report spam to > ab...@vfemail.net > > *ONLY AT VFEmail!* - Use our *Metadata Mitigator*™ to keep your email out > of the NSA's hands! > $24.95 ONETIME Lifetime accounts with Privacy Features! > No Bandwidth Quotas! 15GB disk space! > Commercial and Bulk Mail Options! > > -- 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/bfb49d87-20e4-44c5-af4a-ef2e0e931cec%40googlegroups.com.
[qubes-users] Re: email fetching /reading
On Thursday, May 2, 2019 at 3:02:29 AM UTC+3, haaber wrote: > Dear all, I was meditating (once more) about email fetching. I guess the > qubes way I should > > - use a mail-VM that runs offline-imap and places mail >in different folders, one for each email account. Best over tor, >to avoid being identified (when mobile) via the mail-host-combination >I use. > - start a disp-VM that kills spam and runs some antivirus >(comments invited if that is helpful / needed ) > - then "qvm-sync" (we have that one?) the cleared folders >to the respective mail-reading-VMs (private / work, for me). > > is that the right construction? Cheers, You might want to have a look at my offline mail setup described here: https://www.reddit.com/r/Qubes/comments/9q76f2/splitmail_setup/ It lacks anti-spam/anti-virus part (which is a cool idea, I'll implement this) but otherwise is close to what you describe. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/74f1e926-d4eb-4841-8635-6d3a464918fa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide
On Saturday, December 1, 2018 at 7:05:08 PM UTC, alex.jo...@gmail.com wrote: > At which point did you get this error? > Did you create android VM according to guide? > >Create android VM in dom0: > >qvm-create --class StandaloneVM --label green --property virt_mode=hvm > >android > >qvm-prefs android kernel '' > >qvm-prefs android 'sys-android' > >qvm-prefs android memory '2048' > >qvm-prefs android maxmem '2048' > >qvm-volume extend android:root 20g > What's your Qubes version? It works on my Qubes 4.0. > I think it should be related to kernel option: > >qvm-prefs android kernel '' > https://github.com/QubesOS/qubes-issues/issues/3419 You are right, the issue was due to missing `qvm-prefs android kernel ''`. Everything works fine now, if we can call fine inability to change screen resolution, absence of sound and file exchange and semi-defunct mouse. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/186dc847-f77b-455c-b22e-7905a54ccaae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide
On Saturday, December 1, 2018 at 4:32:59 PM UTC, alex.jo...@gmail.com wrote: > On Saturday, December 1, 2018 at 5:47:52 AM UTC, alex.b...@gmail.com wrote: > > Great guide! The whole process looks way more straightforward than I > > thought it is! > > > > Do you mind sharing the resulting images for testing? I'll have hard time > > compiling this myself on old Core m3/8Gb machine... > > You can try this image, but I advise to build your own image for security > reasons: > https://drive.google.com/open?id=1KGDRe9iJgjb3nSBjFlK74Sa_nn08qYiq Thank Alex! Does not boot for me, vm halts after "Probing EDD" :( That was the whole point of trying pre-built image (despite security implications) - your iso saved me quite a few hours of compiling. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/dfc9ecc6-a3cf-4331-8c64-89bb1a66abaa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide
Great guide! The whole process looks way more straightforward than I thought it is! Do you mind sharing the resulting images for testing? I'll have hard time compiling this myself on old Core m3/8Gb machine... -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3ecfa794-26d0-487f-bb9e-f7b36c544a1f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - GPD Win 2 - Qubes 4
GPD Win 2 - the smallest computer to run Qubes 4. Core m3 7Y-30, RAM 8 Gb, SSD 512 Gb. Everything runs as well as m3 7Y-30/8 Gb can make it. The only issue is non-working sleep (or rather non-working wake from sleep) - hope this will get fixed with kernel updates. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/831e95ce-44f5-4e83-e7d0-228d643bab21%40gmail.com. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-Default_string-Default_string-20181021-084547.cpio.gz Description: application/gzip
