Re: [qubes-users] Default fedora-30 template asking for password that I don't have
>Also, try using `su` with no arguments and see if that asks for a password also. The problem was resolved by using the "su" command on its own (as opposed to "su user", which prompted me for a password), which brought me straight into "bash-5.0#", where I used the "cat > 00-macrandomizer.conf" command. Typing "sudo cat > test.txt" into the user (non-su) prompt returned "bash: test.txt: Permission denied". >Also, don't type your dom0 passwords or disk password into VMs. You may want to change them just to be safe. My machine has never been connected to the internet when I typed in the passwords (like, in the lifetime of the machine), so I figured they'll be safe unless a verified iso has been compromised, but I'll do things the Qubes way and change them anyways. Not a minimal template because it was cloned from the default fedora-30 and left unmolested by my fat fingers. I might play around with minimals in the future, so the info provided might come in handy. >Re: TOR firewall I have the computational resources to spare, so I'll take the paranoid route and firewall my Whonix-15-gw while keeping an eye on SOCKSPorts. This thread has been resolved--thank you, Claudia and Chris. -- 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/fff7fd0e-1630-437e-bb0f-ae6b5c2f97a3%40googlegroups.com.
Re: [qubes-users] Does the latest Linux kernel improve security for qubes?
On 1/6/20 4:11 PM, Claudia wrote: January 6, 2020 8:20 PM, "Chris Laprise" wrote: On 1/5/20 11:30 PM, Claudia wrote: I don't know much about PSP, or ME for that matter, but it seems to me you're mostly screwed either way, so I figured I might as well save some money while I'm at it. This was even before the recent Intel shit show. Indeed. These management engines are ubiquitous, so I think we should try to answer the question: Can they be properly deactivated? Given everything else, its possible the answer is 'no' for Intel (we already know this) and 'yes' for AMD. Plus, I got a really good deal on this particular machine (so admittedly a bit of an impulse buy). And I have to say, despite a lot of troubleshooting and a few remaining glitches, it actually runs Qubes surprisingly well, all things considered. But... yeah, kids, don't try this at home. I tend to shy away from 'consumer' models, bc they almost always misconfigure advanced features like the IOMMU as the firmware isn't carefully managed. Dell describes Inspiron models as "Home and Home Office". On top of that, though, IOMMU problems and ACPI bugs and such appear to be widespread in the Ryzen family, across different computer makes and models, including higher-end ones and motherboards. I think there are some links about it in some of my other threads. That's what makes me think Ryzen itself has some problems of its own, or at least certain generations or something. Bad firmware can break good hardware, but good firmware can't fix bad hardware. Other AMD product lines though like Threadripper for example don't seem to be any worse than Intel from what I've heard. But like I said, it's really not that bad, all things considered -- I now have fully working suspend/resume which is more than a lot of Qubes users can say. That's good to know. I just noticed your long HCL update thread for the AMD Inspiron. Since I'm behind with the HCL list and you put so much work into your report, I'll move yours to the top of my queue. It should get listed sometime this week. Thanks for the detailed reporting! -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/54893d69-9bd4-d31d-aa79-b5a539e84026%40posteo.net.
[qubes-users] Qubes 4 starts, but no VMs will load.
Dear Fellows, I can boot into Qubes normally, except I get some scary looking boot messages (see boot.log contents below.) No VMs will start. After some digging in logs, I found that there was a syntax error on trying to load /usr/lib/tmpfiles.d/qubes.conf. The file seemed to be corrupted, so I renamed it and made a new qubes.conf based on what I found on a working qubes install (I typed it line-by-line, no intentional alterations.) This seems to have fixed the syntax error, but I still can't get qubesd to load, and so can't start any VMs or even start a backup. I'm not sure what to try next. I strongly suspect more corrupt files are to blame. As always, any help will be appreciated. Thanks in advance, T. S. P. Capehart %G %G %G[ [0;32m OK [0m] Started Cryptography Setup for luks-e79f0b60-d59c-4caa-b422-fbca72c62f31. [ [0;32m OK [0m] Found device /dev/mapper/luks-e79f0b60-d59c-4caa-b422-fbca72c62f31. [ [0;32m OK [0m] Reached target Encrypted Volumes. [ [0;32m OK [0m] Reached target System Initialization. [ [0;32m OK [0m] Reached target Basic System. [ [0;32m OK [0m] Found device /dev/mapper/qubes_dom0-root. [ [0;32m OK [0m] Reached target Initrd Root Device. [ [0;32m OK [0m] Started dracut initqueue hook. Starting File System Check on /dev/mapper/qubes_dom0-root... [ [0;32m OK [0m] Reached target Remote File Systems (Pre). [ [0;32m OK [0m] Reached target Remote File Systems. [ [0;32m OK [0m] Started File System Check on /dev/mapper/qubes_dom0-root. Mounting /sysroot... [ [0;32m OK [0m] Mounted /sysroot. [ [0;32m OK [0m] Reached target Initrd Root File System. Starting Reload Configuration from the Real Root... [ [0;32m OK [0m] Started Reload Configuration from the Real Root. [ [0;32m OK [0m] Reached target Initrd File Systems. [ [0;32m OK [0m] Reached target Initrd Default Target. Starting Cleaning Up and Shutting Down Daemons... Starting Plymouth switch root service... [ [0;32m OK [0m] Stopped target Timers. Stopping Forward Password Requests to Plymouth... [ [0;32m OK [0m] Stopped target Remote File Systems. [ [0;32m OK [0m] Stopped target Remote File Systems (Pre). [ [0;32m OK [0m] Stopped dracut initqueue hook. [ [0;32m OK [0m] Stopped dracut cmdline hook. [ [0;32m OK [0m] Stopped Forward Password Requests to Plymouth. [ [0;32m OK [0m] Stopped Cleaning Up and Shutting Down Daemons. [ [0;32m OK [0m] Stopped target Initrd Default Target. [ [0;32m OK [0m] Stopped target Basic System. [ [0;32m OK [0m] Stopped target Sockets. [ [0;32m OK [0m] Stopped target System Initialization. [ [0;32m OK [0m] Stopped Create Volatile Files and Directories. [ [0;32m OK [0m] Stopped Apply Kernel Variables. [ [0;32m OK [0m] Stopped target Local File Systems. [ [0;32m OK [0m] Stopped Load Kernel Modules. [ [0;32m OK [0m] Stopped target Encrypted Volumes. Stopping udev Kernel Device Manager... [ [0;32m OK [0m] Stopped udev Coldplug all Devices. [ [0;32m OK [0m] Stopped target Swap. [ [0;32m OK [0m] Stopped target Slices. [ [0;32m OK [0m] Stopped target Paths. [ [0;32m OK [0m] Stopped target Initrd Root Device. [ [0;32m OK [0m] Started Plymouth switch root service. [ [0;32m OK [0m] Stopped udev Kernel Device Manager. [ [0;32m OK [0m] Stopped Create Static Device Nodes in /dev. [ [0;32m OK [0m] Stopped Create list of required static device nodes for the current kernel. [ [0;32m OK [0m] Closed udev Kernel Socket. [ [0;32m OK [0m] Closed udev Control Socket. Starting Cleanup udevd DB... [ [0;32m OK [0m] Started Cleanup udevd DB. [ [0;32m OK [0m] Reached target Switch Root. Starting Switch Root... %G %G[ [0;1;31mFAILED [0m] Failed to start Qubes DB agent. See 'systemctl status qubes-db-dom0.service' for details. [ [0;32m OK [0m] Started Login Service. [ [0;32m OK [0m] Started The Xen xenstore. Starting Virtualization daemon... Starting Xenconsoled - handles logging from guest consoles and hypervisor... Starting xen-init-dom0, initialise Dom0 configuration (xenstore nodes, JSON configuration stub)... [ [0;32m OK [0m] Started Xenconsoled - handles logging from guest consoles and hypervisor. [ [0;32m OK [0m] Started xen-init-dom0, initialise Dom0 configuration (xenstore nodes, JSON configuration stub). [ [0;32m OK [0m] Started Daemon for power management. [ [0;32m OK [0m] Started Virtualization daemon. [ [0;1;31mFAILED [0m] Failed to start Qubes memory management daemon. See 'systemctl status qubes-qmemman.service' for details. [ [0;1;31mFAILED [0m] Failed to start Qubes OS daemon. See 'systemctl status qubesd.service' for details. Starting Qubes Dom0 startup setup... [ [0;32m OK [0m] Started Qubes Dom0 startup setup. Starting Start Qubes VM sys-usb... Starting Start Qubes VM sys-usb-input... [ [0;1;31mFAILED
Re: [qubes-users] Default fedora-30 template asking for password that I don't have
January 6, 2020 8:45 PM, "Chris Laprise" wrote: > On 1/6/20 3:22 PM, Claudia wrote: > > I think s/he is really using a "minimal" template here. That would cause > sudo to be disabled by default. On these minimal templates, you can only > gain root privs by using 'qvm-run -u root' in dom0 or by using that > qvm-run command to install the 'qubes-core-agent-passwordless-root' > package which adds the no-password sudo capability back. Oh, that's possible. >>> P.S. Does creating a firewallVM just for TOR connection (i.e. proxy between >>> whonix/TAILS appVM and >>> whonix-15-gw netVM) increase security or just waste computational resources? >> >> This came up a while back. I'll try to find the thread for you. In short, I >> remember reading in the >> Tor documentation that anyone with access to your SOCKSPort can potentially >> learn information about >> what sites you're visiting. So in that case, yes, separate whonix gateways >> would be beneficial. On >> the other hand, the Whonix developers know more about this than I do, and >> I'm assuming they did >> everything right. I never got around to investigating though. You might have >> better luck asking on >> the Whonix forum or Tor stack exchange. > > I think you'll find different opinions about this. IMO, as with adding > extra firewall to VPN VMs, it just wastes resources. The VPN or Tor gw > already has 'low' attack surface and firewall capability, and they > typically filter which external gateways they do and don't talk to based > on crypto-enforced identification. Well, to me there's a difference between theoretical attack surfaces and stuff like that, versus official documentation telling you it's not safe to share SOCKSPorts. If that's the case, that is. It was a really long time ago and I don't remember what it said exactly. But yeah, I agree, I wouldn't necessarily go adding redundant VMs just out of paranoia. Personally I only run one whonix gateway even though I probably have enough ram to run a dozen. -- 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/14769721819d68b68ee1815ab4a1a10d%40disroot.org.
Re: [qubes-users] Does the latest Linux kernel improve security for qubes?
January 6, 2020 8:20 PM, "Chris Laprise" wrote: > On 1/5/20 11:30 PM, Claudia wrote: > >> I don't know much about PSP, or ME for that matter, but it seems to me >> you're mostly screwed either >> way, so I figured I might as well save some money while I'm at it. This was >> even before the recent >> Intel shit show. > > Indeed. These management engines are ubiquitous, so I think we should > try to answer the question: Can they be properly deactivated? > > Given everything else, its possible the answer is 'no' for Intel (we > already know this) and 'yes' for AMD. > >> Plus, I got a really good deal on this particular machine (so admittedly a >> bit of an impulse buy). >> And I have to say, despite a lot of troubleshooting and a few remaining >> glitches, it actually runs >> Qubes surprisingly well, all things considered. But... yeah, kids, don't try >> this at home. > > I tend to shy away from 'consumer' models, bc they almost always > misconfigure advanced features like the IOMMU as the firmware isn't > carefully managed. Dell describes Inspiron models as "Home and Home Office". On top of that, though, IOMMU problems and ACPI bugs and such appear to be widespread in the Ryzen family, across different computer makes and models, including higher-end ones and motherboards. I think there are some links about it in some of my other threads. That's what makes me think Ryzen itself has some problems of its own, or at least certain generations or something. Bad firmware can break good hardware, but good firmware can't fix bad hardware. Other AMD product lines though like Threadripper for example don't seem to be any worse than Intel from what I've heard. But like I said, it's really not that bad, all things considered -- I now have fully working suspend/resume which is more than a lot of Qubes users can say. -- 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/7b61a202c5a8f480ed8a0fb10c59c529%40disroot.org.
Re: [qubes-users] Default fedora-30 template asking for password that I don't have
On 1/6/20 3:22 PM, Claudia wrote: January 6, 2020 5:02 AM, fiftyfourthparal...@gmail.com wrote: Hello, Oops, I forgot to reply to this. Sorry. I have a fresh installation of Qubes 4.0.2 on a Dell Inspiron 5593 with an untouched fedora-30 template. Aside from some minor hiccups during installation, no compatibility issues have been detected. (Note: I know more about tech than the layperson, but not enough to call myself a 'techie'). Following the instructions on the Qubes guide to randomizing my MAC address, I cloned the template and attempted to modify it for my netVMs. When creating the '00-macrandomizer.conf' file in the '/etc/NetworkManager/conf.d' folder, I was told that I don't have permission to do so. This struck me as odd, since I recently read Joanna's message in the sudoers' folder about passwordless root. I tried every password that I've set on the machine (including the root password set during installation), but nothing works. Anyone have any idea what's going on? In case it's relevant, the command line starts with "user". If running as user, you'll get "Permission denied" but it won't ask for a password as far as I know. You need to put sudo in front of the command. This is when it would normally ask you for a password, but it *should* just work without asking for a password. Also, try using `su` with no arguments and see if that asks for a password also. Also, don't type your dom0 passwords or disk password into VMs. You may want to change them just to be safe. Run `sudo -l`, you should see User user may run the following commands on fedora-30: (ALL) NOPASSWD: ALL (root) NOPASSWD: /bin/udevadm trigger --action\=add --sysname-match\=event[0-9] When you're prompted for the password, check /var/log/xen/console/gues-fedora-30.log (on dom0) for any problems. You should see an audit line about the su or sudo command. Normally it should say "res=success" towards the end. I think s/he is really using a "minimal" template here. That would cause sudo to be disabled by default. On these minimal templates, you can only gain root privs by using 'qvm-run -u root' in dom0 or by using that qvm-run command to install the 'qubes-core-agent-passwordless-root' package which adds the no-password sudo capability back. You can also tie sudo to a secure yes/no prompt: https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless-root-access-with-dom0-user-prompt https://github.com/tasket/Qubes-VM-hardening/blob/master/configure-sudo-prompt P.S. Does creating a firewallVM just for TOR connection (i.e. proxy between whonix/TAILS appVM and whonix-15-gw netVM) increase security or just waste computational resources? This came up a while back. I'll try to find the thread for you. In short, I remember reading in the Tor documentation that anyone with access to your SOCKSPort can potentially learn information about what sites you're visiting. So in that case, yes, separate whonix gateways would be beneficial. On the other hand, the Whonix developers know more about this than I do, and I'm assuming they did everything right. I never got around to investigating though. You might have better luck asking on the Whonix forum or Tor stack exchange. I think you'll find different opinions about this. IMO, as with adding extra firewall to VPN VMs, it just wastes resources. The VPN or Tor gw already has 'low' attack surface and firewall capability, and they typically filter which external gateways they do and don't talk to based on crypto-enforced identification. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/1ecd1110-2851-ea62-5069-0a7e4fd48a6e%40posteo.net.
Re: [qubes-users] Default fedora-30 template asking for password that I don't have
January 6, 2020 5:02 AM, fiftyfourthparal...@gmail.com wrote: > Hello, Oops, I forgot to reply to this. Sorry. > I have a fresh installation of Qubes 4.0.2 on a Dell Inspiron 5593 with an > untouched fedora-30 > template. Aside from some minor hiccups during installation, no compatibility > issues have been > detected. (Note: I know more about tech than the layperson, but not enough to > call myself a > 'techie'). > > Following the instructions on the Qubes guide to randomizing my MAC address, > I cloned the template > and attempted to modify it for my netVMs. When creating the > '00-macrandomizer.conf' file in the > '/etc/NetworkManager/conf.d' folder, I was told that I don't have permission > to do so. This struck > me as odd, since I recently read Joanna's message in the sudoers' folder > about passwordless root. I > tried every password that I've set on the machine (including the root > password set during > installation), but nothing works. > > Anyone have any idea what's going on? In case it's relevant, the command line > starts with "user". If running as user, you'll get "Permission denied" but it won't ask for a password as far as I know. You need to put sudo in front of the command. This is when it would normally ask you for a password, but it *should* just work without asking for a password. Also, try using `su` with no arguments and see if that asks for a password also. Also, don't type your dom0 passwords or disk password into VMs. You may want to change them just to be safe. Run `sudo -l`, you should see User user may run the following commands on fedora-30: (ALL) NOPASSWD: ALL (root) NOPASSWD: /bin/udevadm trigger --action\=add --sysname-match\=event[0-9] When you're prompted for the password, check /var/log/xen/console/gues-fedora-30.log (on dom0) for any problems. You should see an audit line about the su or sudo command. Normally it should say "res=success" towards the end. > P.S. Does creating a firewallVM just for TOR connection (i.e. proxy between > whonix/TAILS appVM and > whonix-15-gw netVM) increase security or just waste computational resources? This came up a while back. I'll try to find the thread for you. In short, I remember reading in the Tor documentation that anyone with access to your SOCKSPort can potentially learn information about what sites you're visiting. So in that case, yes, separate whonix gateways would be beneficial. On the other hand, the Whonix developers know more about this than I do, and I'm assuming they did everything right. I never got around to investigating though. You might have better luck asking on the Whonix forum or Tor stack exchange. -- 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/de8a36d828a4d7af38bc4f9b1525c345%40disroot.org.
Re: [qubes-users] Does the latest Linux kernel improve security for qubes?
On 1/5/20 11:30 PM, Claudia wrote: I don't know much about PSP, or ME for that matter, but it seems to me you're mostly screwed either way, so I figured I might as well save some money while I'm at it. This was even before the recent Intel shit show. Indeed. These management engines are ubiquitous, so I think we should try to answer the question: Can they be properly deactivated? Given everything else, its possible the answer is 'no' for Intel (we already know this) and 'yes' for AMD. Plus, I got a really good deal on this particular machine (so admittedly a bit of an impulse buy). And I have to say, despite a lot of troubleshooting and a few remaining glitches, it actually runs Qubes surprisingly well, all things considered. But... yeah, kids, don't try this at home. I tend to shy away from 'consumer' models, bc they almost always misconfigure advanced features like the IOMMU as the firmware isn't carefully managed. Dell describes Inspiron models as "Home and Home Office". The Lenovo G505s I have is also consumer grade and can't easily run Qubes bc they stopped updating the firmware in 2015(!) and IOMMU is present but won't work. Only thing that will fix this is flashing it with Coreboot. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/c0d77c76-21de-d59e-7c1c-3a1685a6a4cb%40posteo.net.
Re: [qubes-users] Re: Perplexed, why do so many here seem to prefer Fedora instead of ?
On 1/6/20 9:20 AM, gorked wrote: Thanks for replying. I will keep what you say in mind in using Debian when I get into a position to try out QUBES. Apparently I made a mistake in that, I thought I read on the CentOS Forum that if I did updates, it would receive the same security updates as Red Hat. Perhaps Red Hat is not always the most secure? Or maybe it is that what they really market is support, since that is what a business requires to use Linux? I wouldn't say CentOS security updates were any poorer than RHEL. RH does them bc they reluctantly had to save CentOS from disbanding, even though it is counter to their stated business model. This is one of those "complicated history" issues. BTW, there is a community-maintained CentOS template for Qubes. To Morph this post a bit, being a lot of intrusions are now coming in with the Web Browser, which Web Browser is now the recommended one for Security? I have been using Firefox, with a lot of Addons, but I had to turn off the Java Script to buy items online. This is not such a worry on Qubes if you keep things in separate VMs. But if you must worry about app-level security, I would stick with Firefox on Debian 10 and enable AppArmor (Debian 10 normally has AA enabled, but the Qubes configuration has an unfortunate side-effect where the default is disabled). To enable AppArmor on Debian VMs, you can change the 'kernelopts' VM pref for the template to add two parameters to the default 'nopat': [dom0]$ qvm-prefs debian-10 kernelopts 'nopat apparmor=1 security=apparmor' This will automatically carry over to all VMs based on that template that do not have their own customized kernelopts setting. (If a VM has a custom kernelopts setting, you'll have to add the AA params to it manually.) Also, Firefox is not the only program that benefits from AppArmor. IMO its easy to do and a win-win. Philosophically, I think Qubes users and devs should hold the point of view that while guest VM code shouldn't be relied-on as primary defense, it is best to let the guest OS use all of its own defenses as long as they are default or easy to enable + use. Another thing that can improve security inside a VM is my Qubes-VM-hardening project, which restores user-auth security in VMs (but with yes/no prompts, not passwords) and prevents malware from hijacking the VM startup environment... https://github.com/tasket/Qubes-VM-hardening A note about Whonix templates: The developer for Whonix is already making efforts to include this kind of defense (and more). But for AppArmor, the last time I checked you still had to turn it on yourself. Since Whonix is based on Debian, the procedure is the same as above (use 'kernelopts' setting). Is there a movement to create a standard about what a Web Page should never be allowed to do, to facilitate security on the internet? Yes, there is a movement and tech project headed by Tim Berners-Lee: https://betanews.com/2018/09/29/tim-berners-lee-solid/ https://www.theguardian.com/technology/2019/nov/24/tim-berners-lee-unveils-global-plan-to-save-the-internet I should also mention the I2P project, which over time has developed a different yet comparable approach to security and privacy. Tor (and by extension, Whonix) is also evolving into this approach but Tor's outproxy default is a snag. Surveillance Capitalism now rules. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/536676a4-da0d-3570-83bc-ab31c36c3a74%40posteo.net.
Re: [qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru
December 30, 2019 7:12 PM, "qubes123" wrote: >> The improper grouping is probably somewhere in AGESA, which is provided > >>> to the manufacturers by AMD. It could be because of hardware related >>> limitations, which again are supplied by AMD. Sometimes vendors take >>> liberties (cost cutting measures) with both and break functionality, as >>> their primary/sole concern is that Windows boots. This can especially be >>> the case with consumer class machines such as Ryzen. Agree it would be >>> nice if Xen handled this failure mode more gracefully. Not sure there is >>> much Qubes can do here, though. On the other hand, my older AMD >>> (pre-Ryzen) consumer laptop running Coreboot has correct groupings. > > I could be wrong, but aren't these PCI assignments and hierarchies coded > within the ACPI DSDT table > in BIOS? I guess in some cases they are, and in other cases they're in hardware. For example if you have two devices between a physical PCI bridge, communication between those two devices might be sent across the bridge without ever making it to the IOMMU. I don't think there's any software approach could do anything about that kind of situation. In my case, the USB controllers and most of the other devices are functions of the same PCI device, 00:03.0{1,2,3,4,6}. Therefore most likely any communication between them is happening within the device and not going to the IOMMU (00:00.2). However I don't know if this is because of the physical structure, or if it could be changed by modifying ACPI tables. I guess the only way to know would be to try it. > I remember as if in UEFI the ACPI tables could be overridden somehow... > > Or - since kernel 5.3.x(?) you can supply certain ACPI tables (as files, > stored in initrd) to the > kernel using commandline parameters* (some additional acpi manipulations are > needed to extract the > current dsdt to see what is in there and make changes in aml...) I understand the part about uploading the ACPI tables via initrd, but I would have no idea how to extract them, what they mean, or what changes to make to them. Also, I haven't figured out if ACPI override actually changes the behavior of PCI devices, or if it just spoofs the information provided to the kernel/hypervisor (which would make it unnecessary/ineffective on Xen). According to the OSDev wiki: "AML interpreter can build up a database of all devices within a system and the properties and functions they support (in reference to configuration and power management)." > Or - before all - you can simply try to boot the kernel with cmdline: > acpi=nocrs (or off) and let > the kernel "enroll" the PCI devices. Maybe worth to try - just one reboot... I did some tests by playing sound in a VM and then binding pciback to the USB controllers to simulate passthru. None of them were successful. At the time of the bind command, audio stopped, and the screen would freeze unless nomodeset was on. I did the testing in the 4.1 pre-release. I tested four combinations of parameters: (none), acpi=off, acpi=nocrs, and acpi=nocrs pci=nocrs, each with and without Xen. In the non-Xen tests, iommu_groups was the same every time. In the Xen tests, xl dmesg and xl info were identical every time. In all tests, lspci and lspci -t were identical. Kernel logs and lspci -kvvnn had some differences each time, but nothing that looked important. If I should look for anything specific please let me know. Note, the data was collected right after I logged in, before I performed the passthru. Not one of my better decisions. However the only thing I recall seeing in the logs at the time of the passthru was this, with acpi=nocrs pci=nocrs: xhci_hcd :03:00.4: Host halt failed, -110 xhci_hcd :03:00.4: Host controller not halted, aborting reset. xhci_hcd :03:00.4: USB bus 3 deregistered pciback :03:00.3: seizing device xen: registering gsi 55 triggering 0 polarity 1 Already setup the GSI :55 pciback :03:00.4: seizing device xen: registering gsi 52 triggering 0 polarity 1 Already setup the GSI :52 Could it be a PCI reset related problem? Finally, a possible workaround I thought of is putting sys-usb into PV mode, since PV passthru doesn't use the IOMMU. It wouldn't be quite as secure as HVM, as it wouldn't prevent a DMA attack, but it would still be better than having USB in dom0. However it looks like Qubes 4.1 isn't going to support any kind of passthru for PVs, so I'll ultimately end up back where I started. I don't currently have sys-usb installed, but I might try it when I have some time. -- 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/b88a85b62f2e84c57ec5fbf87f14b9ec%40disroot.org.
Re: [qubes-users] Qubes OS 4.0.2 has been released!
On Mon, Jan 06, 2020 at 08:35:07PM +0100, Diederik de Haas wrote: > On vrijdag 3 januari 2020 03:21:07 CET Andrew David Wong wrote: > > Qubes 4.0.2 is available on the Downloads page: > I'm only seeing 4.0.2-rc3, but not the final one on that page. retracted because a critical kernel bug made it past all testing. if 4.0.2 or the rc3 work for you, all is well. if not, go with 4.0.1 for now. whichever you install, please make sure to update both dom0 and all templates after install. -- 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/20200106194041.GF8973%40priv-mua.
Re: [qubes-users] Qubes OS 4.0.2 has been released!
On vrijdag 3 januari 2020 03:21:07 CET Andrew David Wong wrote: > Qubes 4.0.2 is available on the Downloads page: > > https://www.qubes-os.org/downloads/ I'm only seeing 4.0.2-rc3, but not the final one on that page. The files are on https://ftp.qubes-os.org/iso/ so I assume it's also on other mirrors, but the primary download page doesn't list it. -- 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/4127259.ZEVRj4yrUH%40bagend. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Re: Perplexed, why do so many here seem to prefer Fedora instead of ?
January 6, 2020 2:20 PM, "gorked" wrote: > To Morph this post a bit, being a lot of intrusions are now coming in with > the Web Browser, which > Web Browser is now the recommended one for Security? I have been using > Firefox, with a lot of > Addons, but I had to turn off the Java Script to buy items online. I would definitely not say Firefox is the most secure (though it is among the best for privacy). But the good news is that, that doesn't really matter in Qubes. Qubes always assumes the browser is compromised. As long as you use Qubes correctly (use different VMs for different tasks/identities, use DispVMs where possible, etc), you can mostly rely on the hypervisor instead of the browser for security. For example, use a different VM for buying things online with JS enabled, than for your regular browsing. Arguably there should be security/hardening at all levels and not just the hypervisor, but the Qubes core principle is security by isolation. > Is there a movement to create a standard about what a Web Page should never > be allowed to do, to > facilitate security on the internet? Not sure what you mean. In terms of JS functions and permissions and things like that? The w3c is who decides the standards for what web pages should be allowed to do and access, and even that is not totally standard: ultimately each browser, and each user, makes their own decisions. I don't think there will ever be a universal list of rules that suits all users and all websites. This is more a matter of privacy than security. I.e. no rules or standards are going to prevent a heap overflow vulnerability or something like that. > Surveillance Capitalism now rules. -- 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/b37fd87705416e6d4b1864b283f3e45b%40disroot.org.
Re: [qubes-users] Does the latest Linux kernel improve security for qubes?
> > I'm certainly no expert though. I meant that you seem to be an expert in technology, maybe with a formal background in some form of engineering. I didn't mean to say that you were a Qubes expert, though three years of use and a year of in-depth tinkering does sound like an expert qualification. I wouldn't have been able to do it without the help from the mailing list. My shiny new laptop would've turned into a shiny new projectile if not for the mailing list. I seem to remember an FSF-approved ARM laptop made by some Chinese company > with a funny name a long time ago that ran Debian or something. I remember coming across something like that (memorable, since Chinese laptop companies in the privacy scene are a rarity), but couldn't find any trace of it on the FSF site. I did come across Pine64, though, which offers cheap ARM laptops. Even if there were ARM options, I don't know if the Qubes development > community could really handle it. > I think the biggest obstacle for users is availability, as non-Intel/AMD PCs must be shipped and exposed to the possibility of interdiction for virtually all users. I can't speak for everyone, but I'd feel like my laptop is tainted or just unclean if I didn't buy an off-the-shelf item. Also, non-Intel/AMD Qubes would only serve a very select niche of the Qubes community, which is already a very select niche. Maybe a good stepping stone for enterprise products though (software + hardware offerings--the Apple of privacy and security? One can dream). -- 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/961b7f82-2c10-4b59-8450-99cecad68afb%40googlegroups.com.
[qubes-users] Standalone Win10VM with private networt
I finally was able to get some time to install qubes on an HP laptop that became free to play with. I installed version 4.0 and have updated it a few times. Everything works at this point, except having a USB-VM. I ended up having to let dom0 handle the USB hardware. This is not a problem. My problem is that I set up a Win10 StandaloneVM that works fine by itself, but I am trying to set up a private network between my WorkVM and the Win10VM. I set up a new NetVMx without hardware, a new FirewallVMx, and am using the FirewallVMx for networking the WorkVM and the Win10VM. I followed the qubes instructions for Enabling networking between two qubes (https://www.qubes-os.org/doc/firewall/). My intention is to use the new network to transfer files between the two VMs and to make sure Windows cannot get to the Internet. I can ping the IPs for the FirewallVMx, the gateway, and the Win10VM from my WorkVM, but neither the FirewallVMx nor the Win10VM can ping the WorkVM. Also, after installing a couple of different Remote Desktop tools on my WorkVM, they both fail to connect to the Win10VM. Is there a reason I cannot ping the WorkVM? Can that also be the reason for the Remote Desktop tools to fail connections? Tim -- 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/cbb75e13d92d50a1e3769324ebb596ae%40jamadots.com.
[qubes-users] Re: Perplexed, why do so many here seem to prefer Fedora instead of ?
Thanks for replying. I will keep what you say in mind in using Debian when I get into a position to try out QUBES. Apparently I made a mistake in that, I thought I read on the CentOS Forum that if I did updates, it would receive the same security updates as Red Hat. Perhaps Red Hat is not always the most secure? Or maybe it is that what they really market is support, since that is what a business requires to use Linux? To Morph this post a bit, being a lot of intrusions are now coming in with the Web Browser, which Web Browser is now the recommended one for Security? I have been using Firefox, with a lot of Addons, but I had to turn off the Java Script to buy items online. Is there a movement to create a standard about what a Web Page should never be allowed to do, to facilitate security on the internet? Surveillance Capitalism now rules. -- 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/83b4921a-b7a7-4aed-a685-5bee989bb68d%40googlegroups.com.
Re: [qubes-users] Does the latest Linux kernel improve security for qubes?
January 6, 2020 5:16 AM, fiftyfourthparal...@gmail.com wrote: >> What can I say, I like doing things the hard way. > > Some might say it's good for character building--like climbing Everest with > minimal assistance when > you can instead just hire a bunch of Sherpas to carry you. > >> I don't know much about PSP, or ME for that matter, but it seems to me >> you're mostly screwed either >> way, so I figured I might as well save some money while I'm at it. > > Well, if the motivation is money then I think the amount of time someone with > your level of > knowledge has put into fixing the machine has gone way past $200 by now. I > think you're in it for > the journey. Looking at it that way, you have a good point. I'm certainly no expert though. I've only been using Qubes about three years, and only tinkering with it less than a year at most. I've learned a *lot* in the last six months, and I still haven't even scratched the surface. I wouldn't have been able to do it without the help from the mailing list. > I was going to say "why not an ARM computer" when I realised that a) there > isn't a single non-Intel > or AMD PC on the HCL, and b) ARM computers are hard to come by. Non-Intel/AMD x86 machines suitable for Qubes are probably just as hard to come by, I would imagine. But besides the issue of trust/transparency with regards to AMD and Intel, I think much of the problem is also rooted in the design and cruft of the x86 architecture itself (read Joanna's "x86 Considered Harmful"). There has been some talk about porting Qubes to other architectures like ARM and POWER9, both historically and recently, but I haven't been following it at all and I don't know how realistic any of it is. For example: https://www.mail-archive.com/qubes-users@googlegroups.com/msg31704.html I seem to remember an FSF-approved ARM laptop made by some Chinese company with a funny name a long time ago that ran Debian or something. But yeah, I don't think ARM desktop/laptop computers are going to catch on any time soon. And from what I understand porting to ARM is a little more complicated due to lack of ACPI and all that stuff. Even if there were ARM options, I don't know if the Qubes development community could really handle it. -- 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/141ae179fd5994e307e8150be547157c%40disroot.org.