[qubes-users] Re: Just realized one of the major disadvantages of Qubes OS...
On Wednesday, January 25, 2017 at 7:12:56 PM UTC-8, jkitt wrote: > On Tuesday, 24 January 2017 11:54:34 UTC, qmast...@gmail.com wrote: > > > I was sad when installed VirtualBox, tried launching it and it said that > > something like "not supported on Xen hosts" > > But why would you want to do that? You already have virtual machines at your > disposal.. for development purposes, you might want other kinds. for example, vagrant is a big sticking point. its how we share and collaborate across platforms, so if you want to work on those projects, you better be able to run its vagrantfile. its also used as codified description of processes, sometimes across machines. so you can have a vagrantfile for your a web project that includes a vm for the back end database. more on that here, https://www.vagrantup.com/ another reason you might want it is nested virtualization for its own sake. for example, developing hypervisor management software. for both cases, i just made a vagrant server to use remotely. but that has obvious limitations. -- 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/9d9aba2e-0e6e-4e77-b549-3d30c12ea788%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Just realized one of the major disadvantages of Qubes OS...
On Tuesday, 24 January 2017 11:54:34 UTC, qmast...@gmail.com wrote: > I was sad when installed VirtualBox, tried launching it and it said that > something like "not supported on Xen hosts" But why would you want to do that? You already have virtual machines at your disposal.. -- 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/92fe7061-0ef1-4d28-9ebe-bf9e927f9b39%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] fixed desktop numbers for VMs or at least fixed start desktop for a VM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-01-25 17:26, Oleg Artemiev wrote: > I'm lazy enough to still use old Qubes. Is it possible to assign > fixed start desktop (or range) for a VM in new Qubes? Ability to > bind last window position for next session start is also a good > motivation to upgrade. Qubrs VM manager may appear on diffrent > desktop and this is annoying. It would be grate to be able to > configure 20 virtual desktops and assign their ranges to a specific > VM. > You'd need to install a program for this in Qubes 3.2. There was a thread about it: https://groups.google.com/d/topic/qubes-users/jtjyq8N6bY0/discussion - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYiVS2AAoJENtN07w5UDAwMNwQAIecrazZ+Fvva8OApD7f3tmL Iv0CCrbQTa/2eqpYOJoCuUrQlE7dl3MdGhl8vknPtW5G22zlc3R0fc4sAjMwKpi2 5FY+lQ+xAUxkzTEvQPqMDYDxMMQBPOiFyQ0CqC56yekRDDp0Ke0HCsseYP5o9YhW kIaFi7frNCA/F53az8s1RTV7A0j+8xaePmxK+UwF2tRNJ0hkOq9f0Jj48vTlxNgE LPV4FdPSBXThoIGnoygjetshnPjvdIEcct0DABeh2NfTF7zr0RWLqqBvLtkj/Esf GX+gTyltz4FIooBw2QONh8g+0Nrw2K0SUrMLk5OL2YilIq31/JFXA55pfUlytOAd CRwYI1LvITp6fd3Xe/+ZBYeg1k1GubnAb4DXqZZIN6c39wzqvlXQCnLbnHtvHlLP B0Cd3XDOe7rDNv50ld8DmI8hTq9vWqy/hZ35BLFQ5aNb5aIj8pSN06gLKi5OkJqB b950CfW/o5yGjr/n/FCsXL3S6CICFhJzdhX7d+u3rT8UrcoG9Z5yg5mh0Hh80Vxg pRFxZIxRl+42wIAByVK86vaM7WcDqzV95W4fjP+IAELMsGb0Mc9FXV+f1vWR9IA4 QEufZuioU6rNpLi0Ey5fBu2E3X0HmWw5cpisWkPSEoNQB1zM62krwfKthWJ19gGi uoJ5Pwc/KJpsBbnLxme+ =bL8i -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/da08a5ed-fbfd-6079-4a71-a6573e150763%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Unable to start any VM. Getting: error starting vm: internal error: unable to reset PCI device 0000:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-01-25 14:22, Pietro Speroni di Fenizio wrote: > On Wednesday, January 25, 2017 at 11:13:54 PM UTC+1, Andrew David Wong wrote: > On 2017-01-25 13:27, Pietro Speroni di Fenizio wrote: Hello, we just installed a Qubes in a linux machine I had. Unfortunately the system seem to be unable to start any VM. I always get the same error: ERROR: internal error: unable to reset PCI device :03:00.2 internal error: Active :03:00.0 devices on bus with 000:03:00.2, not doing bus reset Can someone point me to the right direction? I seem stuck as anything requires me first to start a VM, but no VM seem to be able to start. In fact when the computer turns on at the beginning only dom0 is active and even sys-net and sys-firewall are inactive. Many thanks, Pietro > > It sounds like you have this device assigned to more than one VM. > Check the "Devices" tab in the VM Settings for each VM that has any > devices assigned to it. > > > Thanks, > I just checked. Nothing is assigned in the other VM. Only sys-net had 2 of > the three PCI assigned. Once I assigned the third it started working. But now > it gives me a Device not Managed next to the red network icon above. > > Thank you very much > Have you tried setting pci_strictreset to false? (Make sure you understand the security implications first.) https://www.qubes-os.org/doc/user-faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYiVQ5AAoJENtN07w5UDAwXRsP/1miXII9AR/4fTQ5rHQGMGUs /zDhB098GKLgfP+x415tV376HjcGVuLM2wD61BTx+6etJdljwjwvuQ9YSzCYX4Uy AMzIPlwmC/H7/Mqi0L2Dv95paNepKQnOin+W3uFWqejhOInMSR7mwYm5Nb0HBbRu omsMQ9hsGwjpE6FErbT6H15D9mVYlDSGI8+pHqTciTMZgRQORXz8vUUJB1b6lQ+0 BRoflHllYKILVmQd4QL9nzO3fBEApgSPf4Psmvzl+V4wxt2seL27hux5lqgzay9l VgPeNkMfmUqWXQodfy/9NP0Vb1YwZpTumCiDNDDxO20ju8cwgn6bMe1rd3CMsDB8 lSJZRnJ93tYh12IXbxd1vkaORH47HtZhfXEHSsuBNic8kazHhIDjQhawYfVFQnXd S4waYC/cdE2NlJqRNrCyjbyUJxD4i1Wq+MvVjm7u4WnAwlJAcMw1vGR8RsxUg9VD W8jkyCLTNk3JTC1sydTHH++uZ4z6RZ77WaPgVmsB2Wnw/63iiHbqiomLniPJLsrS FI2r2YgNm+SE/LsM4hVzug7cKnlrL2dwBmEOcRhDn1qHLe+66rxxrAWGT9lsjxh7 Vni+SR40kAkgP/PZAbiAoI+7o3UXnUVoKKRH7eC4GwzQ2B9q6nWMj21uY0W79Njc 84Ko8UGtCu0PNezI/5jr =YE9m -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/f03031a3-fb7e-a077-9339-b3341e2632f8%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] fixed desktop numbers for VMs or at least fixed start desktop for a VM?
I'm lazy enough to still use old Qubes. Is it possible to assign fixed start desktop (or range) for a VM in new Qubes? Ability to bind last window position for next session start is also a good motivation to upgrade. Qubrs VM manager may appear on diffrent desktop and this is annoying. It would be grate to be able to configure 20 virtual desktops and assign their ranges to a specific VM. -- Bye.Olli. gpg --search-keys grey_olli , use key w/ fingerprint below: Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/ -- 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/CABunX6O79PrwsXw8F0UN%2BfW%2BzhMLnhHYdEOzuJjETLkZGB%3DkrA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Unable to start any VM. Getting: error starting vm: internal error: unable to reset PCI device 0000:
On Wednesday, January 25, 2017 at 11:13:54 PM UTC+1, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2017-01-25 13:27, Pietro Speroni di Fenizio wrote: > > Hello, we just installed a Qubes in a linux machine I had. > > > > Unfortunately the system seem to be unable to start any VM. > > > > I always get the same error: ERROR: internal error: unable to reset > > PCI device :03:00.2 internal error: Active :03:00.0 devices > > on bus with 000:03:00.2, not doing bus reset > > > > Can someone point me to the right direction? I seem stuck as > > anything requires me first to start a VM, but no VM seem to be able > > to start. In fact when the computer turns on at the beginning only > > dom0 is active and even sys-net and sys-firewall are inactive. > > > > Many thanks, Pietro > > > > It sounds like you have this device assigned to more than one VM. > Check the "Devices" tab in the VM Settings for each VM that has any > devices assigned to it. > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > -BEGIN PGP SIGNATURE- > > iQIcBAEBCgAGBQJYiSMSAAoJENtN07w5UDAw7P4P+wYMA1LsNPhGqKLKZuGLICgk > MfxYtldPdbhlLRC1RFx6bKTdZxpUVpSVtfNszKS56/0dZERonfKwMcGREvZxdHvu > lMxSVvfsPqPG436MH8mEDNU9iMBttNzPKC5tuoxhLGJBz+GPvi708nDRvAXWFylY > IbaU7cih0/7IF8JgQ7/qgE5g4xbGY8nStsJby6aPxumtcrXzt6NHTnFE31KeVDEh > Rw4nARrOc2wrTH6PrEF6AEMjORQbXJau9pzsmQSSFMyLTIpiLIa9LBrEtaRwC6fM > PXJ+NvYtu8YDVT7sli7mdhsdpN0sS83W2ao78yKyfjLHjtPt72o+xLC5a2Y0jg2L > 537EROJpCRpjiwgH5myDSBtGfbfHXzU0d3D9Va6mClxWDPnZ6eThc0/R4ds0CcnN > F2SQsq3LZrXEN1HO2Ec3rUL/AnR2LSuQBRIwznOg+5Q7y9InUcpdO9vQyQPyVl2Q > mWgxc+13nl0DweCNpugbrOa8DXyEKYjt93IuW2/83wG7wQykCDZwkGM2y7sFdBFh > r1bgNpQU2NnN0r6IFHMCcjOV//X54cWYUWVFEHw/AZk86FybclyIhsX/0qFeCvj5 > dgzOD1HLQyOfVH6YKPzglB1GEPelqaEDTri2Jpwx+fR47zyr3UbdM2yrTVOU99WP > 3R04DPOH5UV2m/jUxzYP > =6Ai6 > -END PGP SIGNATURE- Thanks, I just checked. Nothing is assigned in the other VM. Only sys-net had 2 of the three PCI assigned. Once I assigned the third it started working. But now it gives me a Device not Managed next to the red network icon above. Thank you very much -- 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/2129ba99-cd38-4f01-bba3-35491642d482%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On Wednesday, January 25, 2017 at 6:22:14 PM UTC+1, raah...@gmail.com wrote: > On Tuesday, January 24, 2017 at 9:15:10 AM UTC-5, Kopimi Security wrote: > > On Monday, January 23, 2017 at 8:38:56 PM UTC+1, Reg Tiangha wrote: > > > Yeah, I tried it myself leaving my laptop turned on and on learning mode > > > for three weeks straight, but it didn't catch everything and certain > > > things still failed so there's definitely some manual massaging that > > > needs to be done. > > > > Thank you for your input! > > > > Would you think a sniffing approach, or a tripwire approach, to be better*? > > > > * On a RAM-limited system > > what do you mean by sniffing approach? Sorry for being unclear, I'm not a native speaker. By "sniffing", I meant to refer to active monitoring of known attack types, a pro-active approach as opposed to a more after-the-fact intrusion detection system. Kind of like watchdogs for memory, and snort for ports. Google recently wrote up some advice for hardening KVMs: https://cloudplatform.googleblog.com/2017/01/7-ways-we-harden-our-KVM-hypervisor-at-Google-Cloud-security-in-plaintext.html Their number one advice is using a pro-active approach. -- 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/02fa0201-0f4f-43c4-a786-164a6147d35d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Unable to start any VM. Getting: error starting vm: internal error: unable to reset PCI device 0000:
> If you run lspci in dom0 you will get the list of devices and their bus > numbers. If you look for devices on :03:00 this should give clues about > what is going on. Thank you. So apparently the 03:00.2 is the Ethernet controller, the 03:00.0 is a PCI express card reader. In any case I went to the sys-netVM under VM settings> devices and made sure to move all three on the selected list (that was an intuition after seeing part of the video in the quebes that spoke about pci). After that it did not give mt that error anymore. We have moved on the the next error :-). I get an Ethernet Network Device not managed. I added a "vpn connection" or at least I opened vpn connection, and added the data of my wifi, security and password. SSID: [ssid name Mode: hotspot Band: Automatic Channel: default Device: LEFT THIS BLANK Wi-fi security: [wrote the password] But apparently that is not enough. Thanks again for any hint -- 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/f7da22d1-9850-4017-bd14-6c23f897da39%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Unable to start any VM. Getting: error starting vm: internal error: unable to reset PCI device 0000:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-01-25 13:27, Pietro Speroni di Fenizio wrote: > Hello, we just installed a Qubes in a linux machine I had. > > Unfortunately the system seem to be unable to start any VM. > > I always get the same error: ERROR: internal error: unable to reset > PCI device :03:00.2 internal error: Active :03:00.0 devices > on bus with 000:03:00.2, not doing bus reset > > Can someone point me to the right direction? I seem stuck as > anything requires me first to start a VM, but no VM seem to be able > to start. In fact when the computer turns on at the beginning only > dom0 is active and even sys-net and sys-firewall are inactive. > > Many thanks, Pietro > It sounds like you have this device assigned to more than one VM. Check the "Devices" tab in the VM Settings for each VM that has any devices assigned to it. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYiSMSAAoJENtN07w5UDAw7P4P+wYMA1LsNPhGqKLKZuGLICgk MfxYtldPdbhlLRC1RFx6bKTdZxpUVpSVtfNszKS56/0dZERonfKwMcGREvZxdHvu lMxSVvfsPqPG436MH8mEDNU9iMBttNzPKC5tuoxhLGJBz+GPvi708nDRvAXWFylY IbaU7cih0/7IF8JgQ7/qgE5g4xbGY8nStsJby6aPxumtcrXzt6NHTnFE31KeVDEh Rw4nARrOc2wrTH6PrEF6AEMjORQbXJau9pzsmQSSFMyLTIpiLIa9LBrEtaRwC6fM PXJ+NvYtu8YDVT7sli7mdhsdpN0sS83W2ao78yKyfjLHjtPt72o+xLC5a2Y0jg2L 537EROJpCRpjiwgH5myDSBtGfbfHXzU0d3D9Va6mClxWDPnZ6eThc0/R4ds0CcnN F2SQsq3LZrXEN1HO2Ec3rUL/AnR2LSuQBRIwznOg+5Q7y9InUcpdO9vQyQPyVl2Q mWgxc+13nl0DweCNpugbrOa8DXyEKYjt93IuW2/83wG7wQykCDZwkGM2y7sFdBFh r1bgNpQU2NnN0r6IFHMCcjOV//X54cWYUWVFEHw/AZk86FybclyIhsX/0qFeCvj5 dgzOD1HLQyOfVH6YKPzglB1GEPelqaEDTri2Jpwx+fR47zyr3UbdM2yrTVOU99WP 3R04DPOH5UV2m/jUxzYP =6Ai6 -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/b0271ec1-59d1-61d0-4c9c-7c1271cf3e9d%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Linux HVM through Whonix Gateway or VPN
Chris Bensch wrote: > I'm running Qubes 3.2. I have a Debian HVM that works perfect when using the > default sys-firewall as the netvm. If I change the netvm to another proxyvm > such as a VPN (https://github.com/Rudd-O/qubes-vpn) or change it to the > default sys-whonix, I lose all connectivity. Can someone point me in the > right direction? > Do you have it configured using a static IP address? I would try manually changing the route to the configured NetVM. -- 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/1485381120.1167.6.camel%4016bits.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Unable to start any VM. Getting: error starting vm: internal error: unable to reset PCI device 0000:
Hello, we just installed a Qubes in a linux machine I had. Unfortunately the system seem to be unable to start any VM. I always get the same error: ERROR: internal error: unable to reset PCI device :03:00.2 internal error: Active :03:00.0 devices on bus with 000:03:00.2, not doing bus reset Can someone point me to the right direction? I seem stuck as anything requires me first to start a VM, but no VM seem to be able to start. In fact when the computer turns on at the beginning only dom0 is active and even sys-net and sys-firewall are inactive. Many thanks, Pietro -- 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/65f4422b-4578-486e-8e5f-ac7c1c5e1929%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On Wednesday, January 25, 2017 at 12:39:07 PM UTC-5, Reg Tiangha wrote: > On 2017-01-25 10:24 AM, raahe...@gmail.com > wrote: > > > > > It should tell you what rbac is blocking in dmesg or journal no? it will > > say gradm I believe. You should also be seeing grsec and pax messages in > > there as well. > > > > It probably did, although sometimes it'll say what was killed, but not > specifically why. For example, if a process is denied access to a > directory (ex. /var/run or something), it may not be specific enough. > > But in my case, during training, there's a lot of crap that goes into > dmesg, and I didn't discover the actual issues until I restarted the > machines with the new rulesets and I never saved the syslogs before > rebooting. In the case of the UpdateVM where no AppVMs were able to > connect to it and thus wouldn't start, absolutely nothing appeared in > the UpdateVMs logs, dmesg or otherwise. I assume it's some kind of Qubes > process on the UpdateVM that failed to start (or it did but kills > whatever is responsible for allowing an AppVM to connect), but I have no > idea which one; like I said, the developer documentation is a bit > lacking in terms of specifying what exact processes are responsible for > certain tasks, and I think the architecture document is like 10 years > old now and doesn't even reflect how the system works currently. > > Anyways, I'm sure with some more troubleshooting I'd eventually be able > to figure it out, but like I've said, I've dumped enough hours into this > as it is. I'm hoping someone out there with more skill will be able to > come up with a generic Qubes RBAC policy rule set, since I believe it's > something the Qubes community could share among ourselves as whatever > base rules are needed for the Qubes/Xen architecture to work properly > under RBAC would be consistent across all VMs. > > > > > yes you can shut down the system in the middle of training. > > > > Ah, I did not know that. Will it pick up and append where it left off > training wise on the next reboot? Or will it overwrite the training log? > It did not occur to me to shut down in the middle because all the > examples in the documentation say to put the learning log in /etc/grsec, > so I just did it knowing that it'd get blown away on the next reboot. It > didn't occur to me until after I finished testing that perhaps I should > have put those logs in /home instead. But like I said, at that point, I > had already wasted 3 weeks worth of time, and I didn't feel like trying > again. Maybe I'll try again later, but I don't have the time right now. well you got further then I ever did, lol, if you get it working let us know. -- 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/5a5e4ef5-c4d8-42ba-8556-3d96b4332ce8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On 2017-01-25 10:24 AM, raahe...@gmail.com wrote: > > It should tell you what rbac is blocking in dmesg or journal no? it will say > gradm I believe. You should also be seeing grsec and pax messages in there > as well. > It probably did, although sometimes it'll say what was killed, but not specifically why. For example, if a process is denied access to a directory (ex. /var/run or something), it may not be specific enough. But in my case, during training, there's a lot of crap that goes into dmesg, and I didn't discover the actual issues until I restarted the machines with the new rulesets and I never saved the syslogs before rebooting. In the case of the UpdateVM where no AppVMs were able to connect to it and thus wouldn't start, absolutely nothing appeared in the UpdateVMs logs, dmesg or otherwise. I assume it's some kind of Qubes process on the UpdateVM that failed to start (or it did but kills whatever is responsible for allowing an AppVM to connect), but I have no idea which one; like I said, the developer documentation is a bit lacking in terms of specifying what exact processes are responsible for certain tasks, and I think the architecture document is like 10 years old now and doesn't even reflect how the system works currently. Anyways, I'm sure with some more troubleshooting I'd eventually be able to figure it out, but like I've said, I've dumped enough hours into this as it is. I'm hoping someone out there with more skill will be able to come up with a generic Qubes RBAC policy rule set, since I believe it's something the Qubes community could share among ourselves as whatever base rules are needed for the Qubes/Xen architecture to work properly under RBAC would be consistent across all VMs. > > yes you can shut down the system in the middle of training. > Ah, I did not know that. Will it pick up and append where it left off training wise on the next reboot? Or will it overwrite the training log? It did not occur to me to shut down in the middle because all the examples in the documentation say to put the learning log in /etc/grsec, so I just did it knowing that it'd get blown away on the next reboot. It didn't occur to me until after I finished testing that perhaps I should have put those logs in /home instead. But like I said, at that point, I had already wasted 3 weeks worth of time, and I didn't feel like trying again. Maybe I'll try again later, but I don't have the time right now. -- 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/o6anqh%248d4%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On Wednesday, January 25, 2017 at 12:24:57 PM UTC-5, raah...@gmail.com wrote: > On Tuesday, January 24, 2017 at 10:32:18 AM UTC-5, Reg Tiangha wrote: > > On 2017-01-24 7:15 AM, Kopimi Security wrote: > > > On Monday, January 23, 2017 at 8:38:56 PM UTC+1, Reg Tiangha wrote: > > >> Yeah, I tried it myself leaving my laptop turned on and on learning mode > > >> for three weeks straight, but it didn't catch everything and certain > > >> things still failed so there's definitely some manual massaging that > > >> needs to be done. > > > > > > Thank you for your input! > > > > > > Would you think a sniffing approach, or a tripwire approach, to be > > > better*? > > > > > > * On a RAM-limited system > > > > > > > That could help with the networking stuff. When I said stuff failed for > > me, I meant more along the lines of certain services or processes that > > were getting killed by the kernel that may or may not be integral to the > > way Qubes does things. > > > > For example, I have both a FirewallVM and an caching UpdateVM running > > squid. The only real difference between the two is squid; otherwise, the > > UpdateVM is just a glorified FirewallVM. Therefore, one would expect > > that the final RBAC ruleset after training between the two would only > > differ with the squid bits. > > > > After my training and applying the custom rulesets for each VM, for > > whatever reason, no AppVM could connect to the UpdateVM once it was > > active (and therefore, the AppVM wouldn't start), but they had no > > problems connecting to the FirewallVM. So obviously, something was > > missed when training the UpdateVM, but I don't know what it was. > > Furthermore, since I don't know how Qubes is archetectured and what > > binaries and libraries are responsible for certain functions (or even > > where they live!), I don't know what to whitelist. And I don't want to > > whitelist entire directories that have or need access for Qubes or Xen > > bits like /usr/bin or /var because I'd be whitelisting a bunch of other > > things I wouldn't want to be doing either. > > > > That's just one example, though. There were some other things I > > encountered as well, but I also concede that some measure of manual > > massaging of rules is probably going to be inevitable in the end. > > > > Could I figure out exactly what was failing with enough time by tracing > > logs and whatnot? Sure, I suppose. But I've sunk in a lot of hours into > > this project already so I don't have as much time to troubleshoot as I > > did over the holidays. So I'm hoping someone smarter than me can figure > > out next steps, at least when it comes to the RBAC stuff. Or at least > > give some hints on what may need to be white listed. > > > > When it comes to the unexpected behaviors that I encountered, I'm still > > leaning towards certain things in the Qubes/Xen chain for various use > > cases that are getting killed without warning that the training didn't > > catch to add to its whitelist. The Grsecurity documentation says that a > > process or library needs to be triggered at least four times during the > > training in order for it to be a bit more lax when it comes time to > > analyze the training log and whitelist more things related to that > > binary or library rather than just whitelisting the binary or library on > > its own, and so maybe certain processes that are needed for Qubes to > > operate just weren't being called enough even after having three weeks > > worth of training. > > > > For example, stuff being called during start up and shut down would > > never trigger that four time threshold, and it'd be hard to record since > > an AppVM's root file system would be nuked every time (in fact, if > > you're not careful with your training or how you invoke it, your VM may > > not start because none of the Qubes startup processes would be captured > > with the training; I worked around it by adding a line to rc.local to > > start the training right away, which helped with start up, but I was > > never able to find a way to capture what Qubes processes were > > responsible when shutting down so I ended up having to kill all my VMs > > to turn them off since RBAC would kill whatever processes were > > responsible for shut down because it never caught them in its training). > > > > Perhaps the training log could be made to be persistent by placing it > > within /home, but I was under the impression that the system couldn't be > > shut down in the middle of training. I could be mistaken, though, but I > > never tried it regardless. I suppose one could write a shutdown script > > that flushed the training log, the question would be when in the > > shutdown process would it be called. It would need to be one of the last > > things in the sequence, otherwise you would risk not catching everything > > possible. > > It should tell you what rbac is blocking in dmesg or journal no? it will say > gradm I believe. You should also be seeing
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On Tuesday, January 24, 2017 at 9:15:10 AM UTC-5, Kopimi Security wrote: > On Monday, January 23, 2017 at 8:38:56 PM UTC+1, Reg Tiangha wrote: > > Yeah, I tried it myself leaving my laptop turned on and on learning mode > > for three weeks straight, but it didn't catch everything and certain > > things still failed so there's definitely some manual massaging that > > needs to be done. > > Thank you for your input! > > Would you think a sniffing approach, or a tripwire approach, to be better*? > > * On a RAM-limited system what do you mean by sniffing approach? Tripwire is good to have but it will take alot of fine tuning as well so its not so noisy. The open source version default setups are for outdated operating systems. It also takes strict discipline so you don't miss nothing, don't forget to keep keys separate. -- 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/99bff6b9-45da-44c3-a770-a77bdd96a94b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] AEM boot option causes hard reboot/partial shutdown (Lenovo T450s)
On Friday, July 15, 2016 at 3:34:12 PM UTC+2, Chris Laprise wrote: > On 07/13/2016 11:15 AM, Chris Laprise wrote: > > On 07/12/2016 11:15 AM, Chris Laprise wrote: > >> On 07/12/2016 01:48 AM, Chris Laprise wrote: > >>> On 07/05/2016 02:21 PM, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Mon, Jul 04, 2016 at 10:26:51AM -0400, Chris Laprise wrote: > > If I replace the kernel with 4.1 from R3.1, it can make it to the > > AEM target > > and the decrypt prompt. It chokes just after decrypting the > > volumes, but > > that's to be expected. The 4.4 kernel appears to introduce some > > factor that > > causes the crash. > Interesting, have you tried 4.2 kernel from R3.1 unstable repository? > Do you have any means of collecting kernel/xen messages? I guess > you've > already disabled "quiet" kernel option and also removed "console=none" > from xen cmdline. > If this doesn't help, try adding "noreboot" and "sync_console" to > xen cmdline. > > If you have serial console (on docking station?) if would be easier to > reliably get log messages. > > - -- > >>> > >>> I just tried the 4.2 kernel on the stick created by AEM under > >>> R3.2rc1; It seems to work as well as 4.1. > >>> > >>> I'll try 4.4 again removing those boot options. > >>> > >>> Unfortunately, the only docking station here is the kind lacking > >>> serial ports. > >>> > >>> Chris > >>> > >> > >> A bit more info: > >> > >> Removing rd.antievilmaid from 4.4.12 options doesn't help; it still > >> restarts. I also tried 4.4.14 in the unstable repo but that did not > >> help. > >> > >> It appears to be an incompatibility between kernel version 4.4 and > >> tboot. > >> > >> Chris > >> > > > > I am able to get 4.4.* to boot now! The trick was to add > > 'min_ram=0x200' to the tboot options like I used to do--the AEM > > README describes how. > > > > But now I cannot get AEM to seal the secret. Nothing at all about AEM > > is displayed during startup, even though rd.antievilmaid is on the > > kernel options line. > > > > Chris > > > > For the record, AEM is now working on my system. The other thing that > was required was to update the anti-evil-maid package to version 3.0.3. > > Chris Hi Chris, can you confirm that AEM is working now on this preceise laptop : LENOVO T450s (20BWS01D00) If yes, please describe what is required to be modified/setup to make it work. And if confirmed, can someone update the line on the HCL page ? https://www.qubes-os.org/hcl/ Regards -- Fred -- 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/bd3423bf-4a89-40e7-8f2f-366528a733ff%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Redshift in dom0?
On Tuesday, January 24, 2017 at 7:16:54 PM UTC+1, Jimmy Axenhus wrote: > Den 2017-01-24 kl. 18:34, skrev ms.amne...@donotusemy.info: > > On Monday, January 23, 2017 at 4:22:56 PM UTC+1, Kopimi Security wrote: > > > > The only "tweak" I still need is the mouse pointer, as it is unaffected by > > redshift on my Qubes. > > > > Anyone any ideas about that? > > > > > You need to disable the hardware cursor. It's a known limitation. [1] > > I got this in /etc/X11/xorg.conf and it's doing the job nicely. > > Section "Device" > Identifier "Device0" > Driver "radeon" # Replace with your driver > Option "SWCursor" "on" > EndSection > > > [1]: http://jonls.dk/redshift/ Thank you for the suggestion. There wasn't an xorg.conf on my system and generating one "broke" my desktop (only tty worked). I guess I'll have to live with the brighter cursor until I've smartened up on how to get the graphics drivers to work with xorg.conf. A bit off-topic: My laptop has an on-board Intel HD and additional Nvidia GT970m. I was able to install Qubes by switching the graphics to Discreet mode in the BIOS. I have read up on how to install Nvidia drivers, but apparently I didn't need them, unless I want to generate an xorg.conf. My previous linux installation on this laptop didn't like the nouveau drivers and was only willing to play nicely if I installed the Nvidia drivers, but somehow it also worked with the on-board intel HD while being in MSHybrid mode (BIOS). I'm still unsure what exactly the MSHybrid mode does, switching it to Discreet seems to disable the on-board Intel HD as lspci only lists the Nvidia. Maybe one day I'll figure it all out. Having a fully functioning Qubes laptop with a wonky mouse pointer is more than I expected. :) -- 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/874195b0-a94f-4248-8336-cb7aebee29c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Linux HVM through Whonix Gateway or VPN
I'm running Qubes 3.2. I have a Debian HVM that works perfect when using the default sys-firewall as the netvm. If I change the netvm to another proxyvm such as a VPN (https://github.com/Rudd-O/qubes-vpn) or change it to the default sys-whonix, I lose all connectivity. Can someone point me in the right direction? -- 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/280f12a5-6f63-4186-948a-562f11bbba50%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Cannot persistently mount extra partitions
you can specify your modified config copy in qvm-start --custom-config=/path/to/config vm-name -- 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/642d1eae-a1d2-4961-b739-b7bc1b5071f5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes r3.2 bricked
On 24/01/2017 23:30, Ángel wrote: > Bernhard wrote: >> Hello, I bricked my system a bit. Yesterady I decided to follow the >> ..onion update procedure. For dom0 all went well (after reading that I >> must change to whonix-net),but I had to modify the debian-8 and >> fedora-24 repo-files "by hand". No big deal. I could update f24 (this >> morning), but debian bugged a bit. Suddenly I thought that maybe I had >> to put netVM to whonix for the templateVM's as well. With a doubt on it >> I looked up what I did with f24 .. and there, by accident I let the >> dropdown box on "sys-net" instead on sys-firewall (or whonix-net). > I would expect that this would make you lose the firewall protection... > > >> Immediately sys-net derailed and lost network. > ...not sys-net to die. > > > Is any of your /var/lib/qubes/*/*/firewall.xml files 0-bytes? > (if so, delete it -so it gets replaced with default settings- and > restart) > Thank you Angel, for helping me. me@dom0 qubes]$find /var/lib/qubes -iname *.xml finds only some files qubes-*somedate* in backup two xml fies in updates and qubes.xml itself. When I run in me@dom0 qubes]$ dom0qvm-start [some appvm] I get some lines like File "/usr/bin/qvm-start, line 136 then 120 File "/usr/lib64/python2.7/../000QubesVM.py File "/usr/lib64/python2.7/../006QubesProxyVM.py qubes.qdb.Error: (2, 'No such file or directory') and, as I said, nothing starts. I start thinking of a disaster-mode data recovery since I do not know how I could possibly unbrick a system that has no network anymore?! I add some history: after having changed to the .onion repo's, the fedora24 system suggested 123(!) package updates (I agreed). That seemed a lot to me, since I check for updates every day. If I have to guess, it is there that it became a brick. Is it sure that the f24 on qubes-os.org and the onion repo are the same? Can I unroll the last update? Thank you for any hint or help Bernhard -- 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/3e0562fc-916d-72aa-8aa2-656bd6428c63%40web.de. For more options, visit https://groups.google.com/d/optout.
