Re: [qubes-users] USB drive attaches but doesn't display in Nautilus
Also tried attaching the partition with the same result. It's still saying that "special device /dev/xvdi does not exist" (or xvdi1 as the case may be) This recurs across a variety of usb external devices, including those without partitions. On Mon, Aug 27, 2018 at 8:10 AM awokd wrote: > On Mon, August 27, 2018 11:35 am, Ward Family wrote: > > Using fdisk -l in sys-usb (prior to attaching elswhere) produces: > > Disk /dev/sda: 28.7 GiB, 3075200 bytes, 60062500 sectors > > Units: sectors of 1 * 512 = 512 bytes > > Sector size (logical/physical): 512 bytes / 512 bytes > > I/O size (minimum/optimal): 512 bytes / 512 bytes > > Disklabel type: dos > > Disk identifier: 0x > > > > > > Device Boot Start End Sectors Size Id > > Type > > /dev/sda132 60062499 60062468 28.7G c W95 > > FAT32 (LBA) > > That looks normal. Try attaching just the partition instead: > qvm-block attach usb1 sys-usb:sda1 > > Attaching the whole device might have resulted in the partition ending up > on /dev/xvdi1 instead. Running qvm-block by itself after the attach should > tell you what device it's on. > > > -- 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/CAJx9ZAFgMNVyN8UkamQNmSDE8Pe2E6hm%2BPabFQYuAn1H%3D-yD5A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] quality/reliability of ZFS in Qubes 4
Hello, I did search before posting this, and did see some limited references to ZFS in specific cases, but not a clear answer to this general question, so here goes; I'm wondering, how is ZFS support in Qubes as of 4.0? That is, once it's set up properly, can I expect it to run about as fast and/or reliably as it would on any other Linux system with appropriate hardware? I have a zpool for user data set up on a machine whose OS I'm looking to convert to Qubes, and I want to know whether there are any serious stability or compatibility issues I should be aware of going in, especially since Qubes adds all the complexity of its' various virtualization mechanisms on top of an already exceptionally complicated filesystem. (I'm planning to install Qubes itself on a SSD in EXT4.) Thanks. -- 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/a237c61b-ffab-4ee7-b501-601f560dcf32%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] How to cache these disk reads done by the likes of [14.xvda-0]
How to cache these disk reads that are reported by `sudo iotop` on dom0 as: Total DISK READ : 188.51 M/s | Total DISK WRITE : 0.00 B/s Actual DISK READ: 188.92 M/s | Actual DISK WRITE: 0.00 B/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO>COMMAND 13206 be/4 root 51.63 M/s0.00 B/s 0.00 % 0.00 % [14.xvda-0] 13207 be/4 root 54.63 M/s0.00 B/s 0.00 % 0.00 % [14.xvda-1] 13209 be/4 root 49.11 M/s0.00 B/s 0.00 % 0.00 % [14.xvda-3] 13208 be/4 root 33.13 M/s0.00 B/s 0.00 % 0.00 % [14.xvda-2] What's happening here is that some qube(Fedora 28 AppVM) is under memory pressure (/about to run out of memory) and due to how lame kernel is handling that, it does a lot of uncached reads(for whatever reason - yet to be fully determined) well before the in-AppVM Linux kernel OOM-killer triggers to kill the process using most RAM. This effectively freezes everything in that AppVM (none of the windows(like terminals) get updated, it can be Paused/Resumed/Killed from Qube Manager though). This goes on for plenty of minutes, I've yet to see it trigger the OOM-killer. (unless I use 12000MB RAM instead of 4000MB, then I can Pause/Unpause several times and it triggers; but never with 4000MB) So I figure, if, even temporarily, Xen (or what? probably not dom0) would be able to cache these reads that the AppVM is doing (rather than count on that VM's OS to cache the reads(which it can no longer do when under memory pressure) then that out of memory point (inside that AppVM) would be reached sooner and hopefully no AppVM OS freeze would be seen. Is it possible? How? Side question: how can I send eg. sysrq+m to a qube? (seems not possible according to this 2016 post https://phabricator.whonix.org/T553#10438 ? ) -- 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/709b48c4-0b72-4674-b27c-40e7fc2736c4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Luks with yubikey + aem
On Sunday, 17 January 2016 10:51:28 UTC-5, Marek Marczykowski-Górecki wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Thu, Jan 07, 2016 at 01:25:10PM +, Rusty Bird wrote:
> > Rusty Bird:
> > > - To protect the LUKS key with "something you have" -- the AEM
> > > stick -- we could add a secret.luks.encrypted file, which holds the
> > > actual LUKS passphrase (not usually typed in during boot, only when
> > > unsealing fails due to upgrades), symmetrically encrypted with
> > > another passphrase.
> >
> > Ugh, this doesn't prevent a multi-stage attack:
> >
> > 1. the attacker visually captures the disk passphrase during a
> > successful boot
> > 2. later, they take a copy of the encrypted disk and infect the system
> > 3. later, the user attaches the AEM stick and boots; the infected
> > system copies secret.luks.encrypted.sealed somewhere -- cue scary
> > music as STATEFULNESS reveals itself from the shadows yet again; now
> > the user notices the failed unseal
>
> And this is great thing about YubiKey - you can't easily copy it.
> Otherwise yes, AEM stick could be "something you have" factor (not sure
> if exactly the way you've proposed, but something like this).
>
> > 4. the attacker quickly gets to the infected notebook; then reverts it
> > to the original state, and unseals + decrypts the LUKS passphrase
> >
> > Portable Qubes installations limit the attacker to copying only a
> > couple of megabytes of the encrypted disk data during (3), instead of
> > taking a complete copy during (2); they also make the infection harder.
> >
> > Or secret.luks.encrypted.sealed could be on a second-stage AEM stick,
> > which the user should connect *after* verifying the OTP... :\
> >
> > > - To protect the secret from visibility, we could plug in Matthew
> > > Garrett's TOTP concept via a secret.totp file containing the seed.
> > > And then add a non-default GRUB boot entry to unseal the regular
> > > static secret.{txt,png}, in case the user doesn't have their
> > > authenticator device with them.
> >
> > The mobile device's TOTP generator would have to be working in a sort
> > of verifier (not prover) mode, simultaneously displaying OTPs for a
> > couple of preceding and following 30-second time steps. Is there
> > anything like that for Android?
>
> I don't think so...
>
> - --
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJWm7h3AAoJENuP0xzK19csdugH/RV7m3yDqt2nopo1Q5F9X/mJ
> 5JO/IGGCAYjFm+vZChxP0NvU5pfGe1RJEu3UnuG/lQTGppMkT527EzUlzRAQTG23
> z1ioPwu+Y4+iTwdsE1FpeEPsqnZw/yHeBYo0Mo2XcuTuqobe2kEn9ufanovjmFdN
> jbqfTk8UfVdAe7jX7jiEeoU2Oae/btqO0gS8j7W7ktXOSfePeZpXo91eeoAP8bqb
> gR/oXrAtVECEz8QSqwIS4FEUN9Ns8IrcQtRfND/AuApE2JQ2Fs52IHBhMnhBYmCA
> qJtwFGqraarEOuGno8bHpHQ5n0eTP36GQRguAGzLOgwHH/lCAcJZhdTT3sEJaSQ=
> =Lm3q
> -END PGP SIGNATURE-
Any further discussion or thought about this?
I want to use AEM, but I am currently using yubikey Chal/Resp for LUKS at boot
time (https://github.com/the2nd/ykluks).
I am sure installing AEM would conflict in some way.
I would like AEM and ykluks to work simultaneously if possible... or if AEM can
use the yubikey instead of a USB drive, and still be used as 2nd factor to
decrypt the multiple LUKS devices.
--
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/54516264-ed1a-412a-b22f-2d8cb9554609%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Yubikey, luks disk encryption password, and usb-vm ?
On Monday, 5 June 2017 00:33:44 UTC-4, wrote: > On Sun, 4 Jun 2017 22:29:57 +0200 > > > On 06/04/2017 10:03 PM, wrote: > > > When using a usb-vm, my usb keyboard is not accessible at boot time, > > > and thus my disk encryption password must be typed on the built-in > > > keyboard. > > > > > > When not using a usb-vm, a usb keyboard can be used to enter the > > > disk encryption password. > > > > > > When using a simple static password at boot typed by the yubikey > > > (which acts like a keyboard), it has the same limitations as the > > > usb keyboard, wherein it can't type the disk password when a usb-vm > > > is being used. > > > > > > I could not determine whether the documentation discussing > > > challenge-response addresses this problem with boot-time disk > > > passwords as some sub-component > > > ( https://www.qubes-os.org/doc/yubi-key/ ). I only see the > > > screensaver discussed, but not disk passwords at boot. > > > > > > While still using a usb-vm to manage all usb devices, is there any > > > way to authorize the yubikey automatically at boot time so it can > > > type in a password for me? > > > > > > Also, here: ( https://github.com/adubois/qubes-app-linux-yubikey), > > > am I missing the referenced qubes-yubikey-vm and qubes-yubikey-dom0 > > > in the repos, because they don't seem to exist? > > > > > > Thanks! > > > > With USB VM enabled, all USB devices are hidden from dom0 even during > > the Linux kernel boot (but not before). If you need to use USB devices > > during Qubes OS boot (keyboard, yubikey, anti-evil-maid, ...) and > > don't mind rigorously checking nobody has plugged any suspicious USB > > devices into your machine before powering it on (as you should be > > doing anyway), you can follow the steps outlined below. > > > > There's a Linux kernel command line argument you need to remove from > > /etc/default/grub -- find the line starting with "GRUB_CMDLINE_LINUX" > > and drop the "rd.qubes.hide_all_usb" argument. Save the changes and > > rebuild grub configuration using `sudo grub2-mkconfig -o > > /boot/grub2/grub.cfg` and then reboot. > > > > Please note that if you have anti-evil-maid installed, you also need > > to re-run `anti-evil-maid-install` script on your AEM device. > > Unsealing of your secrets will, as expected, fail during next boot. > > > > Once you reboot without this option, you can use any USB device > > normally. > > > > > > Cheers, > > Patrik > > > > Thanks for the clear answer! It took some searching, but it looks like > that for me, that flag was only present in /boot/efi/EFI/qubes/xen.cfg > and it does not seem to require rebuilding grub to work. I didn't see > that location discussed here https://www.qubes-os.org/doc/usb/ under > "Removing a USB qube" either. > > Now, to see if I can get the luks challenge response working rather > than just a static password ... If you're still interested. This solution works great with Yubikey (chal/resp mode), with sys-usb running as your USB Qube. It temporarily allows USB devices during the boot up when it asks for a password (challenge) or the LUKS passphrase. Once done, it then unbinds the USB PCI devices from Dom0, so the USB qubes can handle USB devices as it should. https://github.com/the2nd/ykluks -- 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/a8a40cbd-5431-414a-8192-e27782a9cfc7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL: HP Spectre X360 - 15" i7-8550u 16GB / 512GB / GeForce MX150 /Intel 802.11b/g/n/ac Wi-Fi
Hello, I've successfully installed Qubes OS R4.0 on an HP Spectre x360 with the following specs: CPU: 1.8GHz Intel Core i7-8550U (quad-core, 8MB cache, up to 4.0GHz with Turbo Boost) Graphics: Nvidia GeForce MX150 (2GB GDDR5 RAM); Intel UHD Graphics 620 RAM: 16GB DDR4 Screen: 15.6-inch 4K UHD (3,840 x 2,160) IPS WLED backlit Storage: 512GB SSD (PCIe NVMe M.2) Ports: 1 x Thunderbolt 3, 1 x USB-C 3.1, 1 x USB 3.1 Type-A, 1 x HDMI, 1 x 3.5mm audio jack, 1 x SD card reader Connectivity: Intel 802.11b/g/n/ac Wi-Fi (2x2), Bluetooth 4.2 Camera: FHD webcam Enabled virtualization in the BIOS and that was it. Qubes OS works out of the box, everything I tested so far including the touch screen. Martin -- 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/5ca20ce1-88ec-4e10-ac1e-17c5ef5b3e87%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] TemplateVM of a TemplateVM
‐‐‐ Original Message ‐‐‐ On August 27, 2018 10:48 AM, unman wrote: > On Mon, Aug 27, 2018 at 05:13:29AM -, 'awokd' via qubes-users wrote: > > > On Mon, August 27, 2018 2:02 am, averyfuentes9rs via qubes-users wrote: > > > > > Hola Qubers, > > > For stream-lined management and ease of updating I wanted to implement > > > the following Qubes hierachy: > > > > > > 1. Official FC28-minimal TemplateVM from qubes-itl-templates repo > > > 2. 'FC28-base' TemplateVM, a clone of 1) > > > With same small adaptations > > > > > > 3. 'FC28-$ROLE': TemplateVM which uses 2) as a Template > > > With the goal of creating a role specific template that automatically > > > benefits from all changes made to 2) 4) 'AppVM-$ROLE': AppVM based on > > > 3) + > > > some user settings > > > > > > > > > Trying to create a TemplateVM from a TemplateVM I get: > > > $ qvm-create --class=TemplateVM --template=FC28-base --label=red > > > FC28-Test > > > app: Error creating VM: Got empty response from qubesd. See journalctl in > > > dom0 for details. > > > > > Is a TemplateVM of a TemplateVM an unsupported feature or should I create > > > an issue on github for this? > > > > Unsupported/not implemented, but it's an interesting idea- multiply > > layered templates. Anyways, I think the expectation under Qubes would be > > to clone your 'FC28-base' as many times as needed, then you can apply Salt > > scripts to those to customize further. You can do some limited > > customization (selecting services to start or not) from the AppVM, but > > sounds like you'd like more. > > awokd is right: it's not implemented. > In fact the idea has been raised on these lists a few times before. E.g: > https://groups.google.com/d/topic/qubes-users/a_VX6xSWj-Q/discussion > https://groups.google.com/d/topic/qubes-users/iLJjTTQqgrw/discussion > > You'll see that the current implementation precludes templateception, > and changing to allow it would alter the security profile. > > As awokd says, multiple templates are the way to go. There's some extra > admin pain but you can mitigate this using salt (or a simple bash > script) and a caching proxy. > > unman Thanks for the links. marmareks description of the template mechanism working on block level logically explains why this is not possible. It raises a few other (more or less) random thoughts: 1) The python trace I posted above should not happen. IMO qvm-clone should display an error for this setup being unsupported instead. 2) qubesctl should have something like a '--recursive' flag: Expected behabvior: Lets say I execute 'state.apply' on an AppVM 'FC28-Random', adding the recursive flag would first execute 'state.apply' on the TemplateVM 'FC28-Random' is based on and afterwards apply 'state.apply' to the AppVM itself. I find 2) especially helpful, since software and OS upgrades need to done in the TemplateVM. As a new user to Qubes + Salt (alternatively as I'm prone to forgetting things :-P) I frequently forget to run qubesctl twice to incorporate all changes that I expect to manifest in the AppVM. IMO the '--recursive' flag would make the situation more "working as expected". --- Salud, Avery -- 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/UsT2YfOGoPx2CvemXI_x6u_aO-y9m2L-KJsu1K1TfnNhLOelUdi3coYfkUU4_Iwy1z7IbKmm5QNnTdCNGZS18xFmRpHFy6Mg-n7K6ZAqxsk%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
