[qubes-users] Testers wanted
Hello all, Now that r3.1 is end of life, we need to do some work to clear the 113 bugs that are still open. A first step would be to triage the bugs to see what still affects 3.2 and what can be closed. If you are interested in helping out, please reply to me rather than to the list. Ideally you will have a fairly vanilla 3.2 you can use for testing. If you can send me a note of your hardware that would help in allocating bugs where the original report referred to specific hardware. With a bit of effort we should be able to clear these pretty quickly, and you will have helped make Qubes that little bit better. cheers unman -- 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/20170402031718.GA29195%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Installation from a tarball: any Qubes OS particulars?
Are there any guidelines (specific to Qubes OS) on installation from a tarball? I am asking since the guidelines for installing software https://www.qubes-os.org/doc/software-update-vm/#installing-or-updating-software-in-the-templatevm assume existence of rpm or deb packages. They do not shed light on the installation from a tarball. It is not clear, whether any extra steps should be taken. I wonder how people cope with this situation. For instance: 1) Do you vet the software installer code before running it? (see https://www.qubes-os.org/doc/software-update-vm/#notes-on-trusting-your-templatevms) 2) Do you update the list of available applications in dom0? (see https://www.qubes-os.org/doc/managing-appvm-shortcuts/#what-if-my-application-has-not-been-automatically-included-in-the-list-of-available-apps) 3) Do you assemble RPM (from a tarball) to avoid the hassles 1) and 2) ? 4) From the trust point of view, do you prefer to build binaries from the sources? because (hypothetical reason): a) distributed binaries are not signed b) to make sure the software is linked to trusted libraries only -- 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/1697922883.10486461.1491102112019%40mail.yahoo.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - Alienware 15 R3
The following results are from a HCL run in a Qubes system installed on a USB stick. Feel free to request more tests/hardware info. -- 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/CAD2C_66ykXHKNdXanGRUe6q6DJtUNWmROdd8KCHTC0EJbUC1nw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-Alienware-Alienware_15_R3-20170401-185229.cpio.gz Description: GNU Zip compressed data Qubes-HCL-Alienware-Alienware_15_R3-20170401-185229.yml Description: application/yaml
Re: [qubes-users] Qubes R3.2 Installer Fails to Detect Disks on MacBookPro11,1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-04-01 06:53, berzerkati...@gmail.com wrote: > Hi everyone, > > I was hoping that somebody could shed some light on this. > > Booting the installer (via legacy BIOS and also through EFI using > rEFInd) results in the installer not detecting any disks. This is a > MacBookPro11,1 with an SSD. > > Any ideas would be really appreciated. > > Thanks, Chris > I don't have any specific help to provide, but make sure to take a look at this page, if you're not already aware of it: https://www.qubes-os.org/doc/macbook-troubleshooting/ - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJY4E7CAAoJENtN07w5UDAwLn4P/Anwm/ys1NkxoPSJAt0ir1kT RMRGohwfpVPFQiqfluT3fo89MGHjnhhTUud1kwFLuDztze3AEVPBS4m4W2h8YkwT 5+HA/yEr44ed50uyRAGNDTfrPLeQ/UMB0aBDZU8LP6CkGqELVqlcIk7cTEX/C1E1 kqfQ6ybZmKnnzxT4cVR9D5C4jpJ08W83K9/nQ7WVcLfbqlsneSSRj9KPPsIwNId0 w8J0oFfVcu0aObDOEm9R+WpdOx9YzA7LS20r3wdjBWFNBHUGFGbjgLSBgdKDptix 1YUvD6mNY1EjGbM0O/qAENdgzpLdzYaMnaXr1MSBmznL+eYCSbY3l5r7rXvnvVOp bST/zay2bJVmlr7JK3noLmMzPe/jp13wW7w9SA2MeeFdSohsW845TG8EiMogFvoE Q8VMF5V9GT1ham/+FZpNbmghBg0IaTXpJLmyJbHcm3MdT2hJSFcnyxtWWx6zIGFY 4QjsCx8VUarvrScOX0FIygdI1oOu21bCXv+Tk0kY13pdWbyGvlk02tnr/TcpNOmZ J/pV4vE+5SQarwO6Bv7+V1wiTl/JDOOWkPTmGK2y4w4EzNak4TnXv4kxDuvu5mvk ag/D+o/FpO7QrvQUhU2RgKy33lZXstqsDKn3tjBTLPYeD/cDyn5NG2r4HuzLYrhP AIJ+W888X58vgxPHzjQW =rVbs -END PGP SIGNATURE- -- 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/54577320-3894-1241-e495-101daf0b98be%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Is it possible to download Qubes 3.2 from Github?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-04-01 11:23, qubestheb...@tutanota.com wrote: > Hi. > > On my network many websites are blocked (to be precise only a > handful are allowed). However one can get access to github.com. > > Is it possible to download Qubes 3.2 from Github? > > Thank you. > You can download the source from GitHub and build it yourself, but I'm afraid none of our ISOs are on GitHub. Here's a list of our available mirrors: https://www.qubes-os.org/downloads/#mirrors If none of those are whitelisted for you, I (or someone) can probably share the ISO through, e.g., Google Drive, if that would work. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJY4E4iAAoJENtN07w5UDAwoi4P/R1iVk283lFpmq8+UHoArem8 XI2/Cl5xuObqady5E4/9z+2IlZvn1g5h94eUlPc8OJIbz/VXAAzH8uxbncB6Mb+d 8wmSZoNvYiCp5g49n8+PD0X7A7mXCGU/IavIf7M1qCLnv8Eg59uBQW/XlsK63/xu Vf0QRZDu90+iLSivqLtcV4wTwoQuLPZjSWgk5a6MTz+jRFpWnIrF2ATI9sF/kJIH ra74EeZlnccbjJpTm+lAYj5RjVNtZkcpVGDRiq6KndS9zdruTg+tzwnJ1KJJJxqI GSBndGRwA1HTPp5cJ35SqiOaRfgUDrQ6yqDJ/vb11VZZ+PBQiFiTKbXjEbLmZ1Wi eT1CJ2Jy+dTvey06nxDHCjdiUVZL2cfzH4S4JJL4Cr2ulQP9X4jdg0GygfLJq44h bfT6C+FNO89lSIbUIT4x6G/R/ago5Cju3jFswPrzCuacgnSz2LASsVdu4kmBijiY R5gp8KINIP3UPD9gd2gVWNzGFmswOfFKAl4bDSK23Lx2lE10ldj+pZOiLOiXrz+f fLzzpgAGTuJIctdJTGfTwdbkX93V8MzdZUB2nIDlVDXBxu01ig7eSeltrDQY87uY s6q7ET76pnBXm8eLsrEYIsbTodieIvhnsigvJFIeWC+fwgtLdaXWDoXHM8t5TzT+ LzZuwuO3RFURKmaJ0Mq7 =OKdo -END PGP SIGNATURE- -- 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/804ae160-7ce5-b716-3d8b-885a0d12ac33%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3 MacOSX
On Saturday, April 1, 2017 at 5:31:36 PM UTC-7, Eric wrote: > 4) google a bunch (IIRC there is some info floating around on the QEMU > mailing list that might help). http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ looks like Eric Shelton who provided the patches up-thread did most of the work on this. -- 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/977ec4e5-6f87-4fb5-9086-69d33260e3d3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3 MacOSX
Most of the following removed for brevity: On Sunday, November 6, 2016 at 4:37:15 AM UTC-8, Achim Patzner wrote: > > Point is: You can't buy a valid license without buying a machine with > it. I guess you could buy *heaps* of Mac mini just to obtain licenses... > Just like having to buy defective power supplies to get MagSafe > connectors. And Apple does not attack the people breaking the licenses; > they are usually aiming at those who enable others to break them (which > I regard as a good thing). > > > Achim Most of seems a bit misinformed (or at least very confusingly worded), and thankfully Apple's own SLA provides us with very direct answers: "B. License from Mac App Store. If you obtained a license for the Apple Software from the Mac App Store, then subject to the terms and conditions of this License and as permitted by the Mac App Store Usage Rules set forth in the App Store Terms and Conditions (http://www.apple.com/legal/itunes/ww/) (“Usage Rules”), you are granted a limited, non-transferable, non-exclusive license: [several sections removed for brevity] (iii) to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software." This is the license for the NON-SERVER version of Mac OS X Lion, 10.7, and every operating system since then has had a similar provision. This means that yes, you do need to run it on Apple hardware, but you can run up to three copies of OS X, or two in a virtual machine presuming you were using Xen or ESXi. Macs have good VT-d and VT-x support, but since they don't use PS/2 for trackpad and keyboard, or have a TPM, it would be a terrible platform to run Qubes on (trust me, I've tried). Not to mention that HiDPI support is still a work in progress - I miss my retina display something awful. Which brings us to the real question, how do we get this to work on Qubes today, on a non-Apple laptop? 1) accept that the developers will not work on making this happen, because Mac hardware is not a good target for Qubes unless something changes, and the dev's very limited time is much better spent elsewhere, especially given the potential for SLA abuse. I for one would much rather see Qubes 4 ship, than have macOS patches land. 2) accept *individual* responsibility for breaking a software license agreement. 3) try to make it work (not sure if those patches above still work in Xen 4.7, but Xen 4.7 might also have some of the newer code needed to make it work). ¯\_(ツ)_/¯ Also accept that if you have to patch Xen with code downloaded from a mailing list, you're probably downgrading your dom0 security, and therefore the overall system security, by a fair amount. 4) google a bunch (IIRC there is some info floating around on the QEMU mailing list that might help). 5) celebrate or drink, depending on the outcome. possibly both. -- 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/686c034b-0bc4-420c-aa97-ddd864699e65%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3 MacOSX
On Sunday, November 6, 2016 at 4:37:15 AM UTC-8, Achim Patzner wrote: [etc etc etc etc removed for brevity] > > Point is: You can't buy a valid license without buying a machine with > it. I guess you could buy *heaps* of Mac mini just to obtain licenses... > Just like having to buy defective power supplies to get MagSafe > connectors. And Apple does not attack the people breaking the licenses; > they are usually aiming at those who enable others to break them (which > I regard as a good thing). > > > Achim Most of this is untrue, and thankfully Apple's own SLA provides us with very direct answers: "B. License from Mac App Store. If you obtained a license for the Apple Software from the Mac App Store, then subject to the terms and conditions of this License and as permitted by the Mac App Store Usage Rules set forth in the App Store Terms and Conditions (http://www.apple.com/legal/itunes/ww/) (“Usage Rules”), you are granted a limited, non-transferable, non-exclusive license: [several sections removed for brevity] (iii) to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software." This is the license for Mac OS X Lion, 10.7, and every operating system since then has had a similar provision. Yes, you do need to run it on Apple hardware, and, since Macs don't use PS/2 for trackpad and keyboard, it would be a terrible platform to run Qubes on (trust me, I've tried). They have good VT-d and VT-x support, but no TPM, and a bunch of really-well-performing wifi chips that don't work very well with Qubes either. Not to mention that HiDPI support is still a work in progress (though I miss my retina display something awful). Which brings us to the real question, how do we get this to work on Qubes today, on a non-Apple laptop? 1) accept that the developers will not work on making this happen, because Mac hardware is not a good target for Qubes unless something changes (which is doubtful, since Apple is going more and more crazy with proprietary stuff, making it harder and harder for Linux to write drivers), and this use case, while super helpful for a small number of folks, would. 2) accept *personal* responsibility for breaking a software license agreement. 3) try to make it work (not sure if those patches above still work in Xen 4.7, but Xen 4.7 might also have some of the newer code needed to make it work). ¯\_(ツ)_/¯ 4) google a bunch (there is some info floating around on the QEMU mailing list I believe). 5) celebrate or drink, depending on the outcome. possibly both. -- 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/3beab201-dd3d-4bfb-9e56-cf2126c7d6e1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: USB Headset
W dniu sobota, 1 kwietnia 2017 18:20:40 UTC+2 użytkownik Stephan Marwedel napisał: > Dear Qubes user community, > > I want to use a USB headset (Jabra Evolve) for the purpose of using my > laptop as a replacement for a desktop phone. Is that possible with > Qubes? If so, what are the settings I need to tweak for that? > > Can I use it also inside a Windows HVM to enable the use of proprietary > conferencing software from Cisco? I have tried it using a Windows VM > with VirtualBox on CentOS 7. That worked, although the audio quality is > pretty bad. Do I need special settings for my Windows HVM in order to > use the headset? > > Regards, > Stephan I did a similar thing with my sound card that requires proprietary Windows only drivers to operate. First, check whether VT-d is available and enabled on your laptop with xl dmesg|grep VT-d Second, identify the number of available USB controllers with sudo lspci|grep USB. If you have more than one controller, assign it to Windows HVM. Within Windows HVM install USB controller driver (if it's a USB 3.0 or later) and then install drivers for the headset (if required). I am able to use the soundcard in the Windows HVM with no problems so you should too. Remember to enable VT-d in BIOS/UEFI first. -- 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/9df440ce-748c-49bf-9375-2a6623a0ef2d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] HDMI-related threats in Qubes OS
On 04/01/2017 04:58 PM, Vít Šesták wrote: Hello, I've realized that HDMI offers not only graphical/sound output, but also many inputs. Well, some inputs are expected (listing of available output modes etc. works AFAIK even with VGA), but others can be more or less surprising: * audio return channel * CEC * ethernet (!) * maybe even more Let's assume I have connected an untrusted HDMI device to my laptop with QubesOS. I am aware that screen output will be passed to untrusted device (e.g., I don't read private e-mail on the screen, but maybe I show some public presentation). What can happen if the device is malicious? Can it pass compressed or otherwise complex sound input to dom0? Can it control my laptop over CEC? Can it connect dom0 to network? Will dom0 ignore the HDMI network? Can anything else bad happen? (Yes, the device can pass too high voltage to my laptop, but this is not the kind of attack I can reasonably resolve.) Maybe you assume that screen should be trusted. This is not always the case. Let's assume we connect to our laptop variously trusted HDMI output devices, ranging from private external screen (most trusted screen) to shared internet-connected and DVB-connected TV with outdated crappy firmware (least trusted). If you are interested in digital TV security, look at https://www.bleepingcomputer.com/news/security/about-90-percent-of-smart-tvs-vulnerable-to-remote-hacking-via-rogue-tv-signals/ . As mentioned above, need of connecting laptop to an untrusted HDMI output is pretty reasonable provided you respect the level of trust of the screen. Regards, Vít Šesták 'v6ak' I think having a graphics driver that disables any auxiliary modes (on the GPU) would be a reasonable first step in addressing the issue. It may also be possible to disable HDMI ports in favor of simpler ones like VGA. I'm not sure how much input DVI and Displayport allow, but I think there's a chance that DVI is similar to VGA in this regard. -- Chris Laprise, tas...@openmailbox.org 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 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/c1174f02-5ff8-2fd0-40e2-3da1a2fb8995%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HDMI-related threats in Qubes OS
Hello, I've realized that HDMI offers not only graphical/sound output, but also many inputs. Well, some inputs are expected (listing of available output modes etc. works AFAIK even with VGA), but others can be more or less surprising: * audio return channel * CEC * ethernet (!) * maybe even more Let's assume I have connected an untrusted HDMI device to my laptop with QubesOS. I am aware that screen output will be passed to untrusted device (e.g., I don't read private e-mail on the screen, but maybe I show some public presentation). What can happen if the device is malicious? Can it pass compressed or otherwise complex sound input to dom0? Can it control my laptop over CEC? Can it connect dom0 to network? Will dom0 ignore the HDMI network? Can anything else bad happen? (Yes, the device can pass too high voltage to my laptop, but this is not the kind of attack I can reasonably resolve.) Maybe you assume that screen should be trusted. This is not always the case. Let's assume we connect to our laptop variously trusted HDMI output devices, ranging from private external screen (most trusted screen) to shared internet-connected and DVB-connected TV with outdated crappy firmware (least trusted). If you are interested in digital TV security, look at https://www.bleepingcomputer.com/news/security/about-90-percent-of-smart-tvs-vulnerable-to-remote-hacking-via-rogue-tv-signals/ . As mentioned above, need of connecting laptop to an untrusted HDMI output is pretty reasonable provided you respect the level of trust of the screen. Regards, Vít Šesták 'v6ak' -- 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/cf0eef81-ba63-47bc-a8ab-4ef11378f18d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] USB Headset
Well, this is not going to be so straightforward. For using it with Qubes (but not with Windows), the easiest way is to connect it to an USB controller connected to dom0 (provided you trust the device enough). Well, it depends how many USB controllers you have etc. If you have two USB controllers, you can assign one to dom0 and one to sys-usb. If you have just one USB controller, then you have to assign all USB devices to dom0, or assign all USB devices to sys-usb. Unfortunately, this will not work on Windows, because Windows has no drivers for Qubes audio. Alternatively, you can connect the device to a controller connected to USBVM (probably sys-usb) and then connect the USB device to the VM you need through qvm-usb. This implies less trust to the device, but the audio from/to the device works just for one VM. The third way is assigning whole USB controller to a VM you need the USB device in. You will probably have no reason to prefer it over the first two options on Linux, but it can be useful in Windows. Unfortunately, this can be problematic: * I am not sure how well it works with HVMs in current release. I remember there were some issues, but I don't know if they are resoolved or not. * PCI pass-through currently requires VT-d support or usage of PVMs. Note that PVMs cannot be used with Windows, so you will probably need VT-d. Regards, Vít Šesták 'v6ak' -- 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/88119ff1-7aab-46da-bad2-60a9af60c365%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Is it possible to download Qubes 3.2 from Github?
Hi. On my network many websites are blocked (to be precise only a handful are allowed). However one can get access to github.com. Is it possible to download Qubes 3.2 from Github? Thank you. -- 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/KgekW1z--3-0%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes R3.2 Installer Fails to Detect Disks on MacBookPro11,1
Hi everyone, I was hoping that somebody could shed some light on this. Booting the installer (via legacy BIOS and also through EFI using rEFInd) results in the installer not detecting any disks. This is a MacBookPro11,1 with an SSD. Any ideas would be really appreciated. Thanks, 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 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/af865366-0382-4186-8074-a71ef633b223%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How much important is TPM?
I agree that secure boot is not a good protection against malware. Even if we consider just dom0 protection, without considering AppVMs: With systems allowing a limited level of customization (e.g., ChromeOS or Android), this might provide a limited level of protection. It can guarantee that you boot a signed image with a signed root filesystem (see dm-verity). On Android (and probably also on ChromeOS), writable (and thus unverifiable) partitions are usually mounted with nosuid and nothing seems to be executed from them with root privileges, so you are *theoretically* protected. But don't overrate this protection: As soon as some suitable vulnerability is found in the kernel or other privileged component, the malware can root the phone on every boot and even take full control and prevent kernel update (blue pill or chainloading). And even if some vulnerability is impractical for rooting on boot (e.g. it takes hours until winning a race condition), the malware could downgrade the kernel to an older version that has more known vulnerabilities. With system allowing you to install any driver, the first driver that is loaded can contain malware and so on. Qubes is today the latter case. Maybe ITL with some partner could sell laptops restricted to boot some restricted QubesOS only, so one would not be easily able to run unauthorized software in dom0. This would be essentially the first case where secure boot offers a limited security advantage. But I don't think it is worth the work and the restrictions. QubesOS tries to prevent the attacker from getting into dom0 in the first place, which has better benefit than we can get from secure boot. When protecting against evil maid, the situation is different a bit. We assume that the attacker has some limited physical access (e.g., she cannot replace your CPU with some backdoored version), maybe she is just able to boot some custom OS image. So the can modify any content on your HDD/SSD. However: * If she modifies grub or some similar component, she should be caught by AEM. * If she wants to modify something else (e.g., some bash script in dom0), she will need to alter the encrypted drive. While encryption is not generally a good protection against modification (see malleablity of stream ciphers or CBC mode or some other ciphers), it can provide a poor man's authentication if the cipher is not malleable in a much practical way and/or the attacker does not know the position of the file to alter. Worth to mention, this is the main difference from malware running in dom0 that has also access to a mounted filesystem. The problem is: 1. The AEM is not perfect. Various vulnerabilities have been published and I am unsure what level of real protection (i.e., not just obscurity) can it provide. 2. AEM is not for free. When filtering only laptops with TXT+TPM, you have quite limited options, selection will take more time and it will probably result in a more expensive laptop. It is really worth the limited protection? Regards, Vít Šesták 'v6ak' -- 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/99581bcf-e80b-49c4-9f71-befa1e0b6139%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] [4.398471] - Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block (0.0)
Had qubes-os installed on 64gb USB stick. Was everything working fine for 1 day. Yesterday I was in the VM manager and saw updates available for dom0, whonix and fedora. Through the terminal I started the updates. Took a while but all three was updated. Today I started to launch Qubes again and got this error. [4.398471] - Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block (0.0) [4.398508] CPU: 0 PID: 1 Comm: swapper/0Not tainted 4.4.38-11.pvops.qubes.x86_61 #1 [4.398571] 73d2c1cb 8801583fbda8 813b1a93 [4.398667] 81a3ec60 8801583fbe40 8801583fbe30 8119ea2e [4.398762] 623000200010 8801583fbe40 8801583fbdd8 73d2c1cb [4.398858] Call Trace: [4.398884] [] dump_stack+0x63/0x90 [4.398912] [] panic+0xd3/0x215 [4.398940] [] mount_block_root+0x201/0x294 [4.398969] [] mount_root+0x65/0x68 [4.398996] [] prepare_namespace+0x13a/0x172 [4.399025] [] kernel_init_freeable+0x205/0x229 [4.399056] [] ? rest_init+0x80/0x80 [4.399085] [] kernel_init+0xe/xe0 [4.399112] [] ret_from_fork+0x3f/0x70 [4.399140] [] ? rest_init+0x80/0x80 [4.399172] Kernel Offset: disabled. -- 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/9c023fad-b849-416c-b935-ba4ea8c21340%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Qubes network server
Hi, before trying it: Is it still maintained? (working with Qubes 3.2) If so: There are a few formatting errors in the readme that make it hard to read https://github.com/Rudd-O/qubes-network-server/blob/master/README.md thanks, Joonas -- 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/eabf2a07-4471-51d6-b13c-a4c77085ebf8%40openmailbox.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[qubes-users] Alias interface file does not persist
Hi, I tried to add an Alias interface configuration files in: /etc/sysconfig/network-scripts/ifcfg-eth0:0 but it does not work. Of course, I used bind-dirs as usual, but here, the file itself: ifcfg-eth0:0 does not persist, but directories does… -- 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/obntbo%244pk%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How much important is TPM?
On 03/31/2017 10:45 PM, cooloutac wrote: On Friday, March 31, 2017 at 4:20:09 PM UTC-4, Vít Šesták wrote: Thanks for your responses. p In this thread, I'd like to discuss how much can it help (i.e., how hard is it to bypass). On self-encrypting devices: I generally don't trust those implementations to be well-reviewed and well-designed, so SED is not a use case for me. Regards, Vít Šesták 'v6ak' I think secure boot would make it better, but maybe a controversial thing to say. I don't know much about this subject myself, but I don't think it actually stops anything. Just lets you know if something has changed. Like a file integrity program kind of. And if something does change there is no fix so you will have to replace all the hardware. (If thats something you're willing to do). You can also do other things like nail polish on screws or crevices. photo them before you leave it unattended... strongbox? lol Microsoft's "Secure" boot is made for security, as in - the security of their income stream. So what you can't easily mess with the boot loader, well that doesn't matter as you can still replace critical system files (verifying all these would take too long and could cause problems) You aren't allowed to install a new boot loader with a SB system unless it comes with the disablement option - that's it. It is a signing key based loader for EFI, but you can do the same thing with a variety of FOSS boot-loaders just without supporting their bullshit. One day you won't be allowed to install linux on "your" (theirs) computer, already 99% of computers are not owner controlled as they were a decade ago - and secure boot 2.0's spec removes the disablement option mandate and 3.0 will probably be enforced with some kind of ME/PSP scheme. -- 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/793e196f-78eb-18f4-66a9-9a3e6a0babe3%40gmx.com. For more options, visit https://groups.google.com/d/optout.