[qubes-users] Re: Unable to uninstall or reinstall Whonix
> I looked at Arm again. It seems that Arm is working, but I don’t know the commands to edit the Tor configuration. > > Arm mentions a list of problems relating to Tor (http://imgur.com/XrJHKSK). It seems that I have relaying disabled, torrc differs from what Tor is using, there is insufficient uptime, Tor is preventing utilities like netstat and lsof from working, and no armrc is working. Unfortunately, I can’t figure out how to solve these problems. > > This is the link I found in the bottom of the Arm report: https://trac.torproject.org/projects/tor/ticket/3313. I’m not too sure what it means.. > Forgive me, Person, but maybe you should be reinstalling at this point. You are asking for lots of help with all these problems; the people helping you probably have other things to do. Try again from scratch and resist the urge to "customize." I used to break lots of installs that way, until I reigned in that behavior. Don't proceed with customizations unless you are fully aware of the consequences. -- 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/orbh0u%24oop%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Possible to add second interface to sys-firewall?
Assuming you mean a physical interface. -- 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/or8a8m%2448c%242%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Possible to add second interface to sys-firewall?
> What I would like to do is add a second IP to both sys-firewall and > sys-net so that I can NAT traffic from one of my VM's in/out through > these IP's. So what I end up with is two IP's on sys-net, one handling > all the traffic for most of my VM's, the other handling traffic for one > specific VM. This way I can do additional firewall restrictions on this > VM in my networks. > > If I manually add the IP addresses to sys-net and sys-firewall, manually > add the destination NAT and source NAT rules to both as well, then > manually add a route in sys-net, and also force another rule into the > IPTABLES raw table on sys-net (to override a rule added by > /etc/xen/scripts/vif-routes-qubes which restricts all incoming traffic > from sys-firewall to the IP assigned by qubes to the default interface), > then I'm able to make this work. > > However, this is very finicky and totally unscriptable in this > configuration, and I'd really like this to be something auto configured > on boot. > > I've look and looked and don't see where I can add a second interface > definition to any config files. If I manually edit the xen > sys-firewall.conf file it just gets overwitten by qubes. I can do all > the iptables rules I need in the /rw/config scripts, but what I really > need is for sys-firewall to add another virtual interface for me. > > I tried running: sudo xl network-attach sys-firewall > script=/etc/xen/scripts/vif-route-qubes ip=10.150.10.10 backend=sys-net > This will add the interface and setup sys-net with the correct routes > and rules, HOWEVER, the interface that it adds to sys-firewall has the > same IP as the existing interface which breaks all the traffic going out > of sys-firewall > > Has anyone ever had any success doing something like this? > > Any suggestions out there? > > Thanks, > Ed > Can you create another sys-net chain with the second interface? You could keep things isolated without scripting. Assuming you are using Qubes 3.2, the interface could be assigned to sys-net-2 via VM Settings->Devices. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/or8a5b%2448c%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Is it damaging to increase each 2GB VM storage beyond the drive limit?
yuraei...@gmail.com: > Heya, > > TL:DR > Is there anything wrong with pushing VM partitions beyond the physical drive > size, as long as data doesn't exceed the physical drive size (which it can't > for obvious reasons). Corruption? Backup size? Privacy? or just no code > available yet to tailor VM sizes to unique drive sizes? > > - - - - > > These 4 questions above reflect the confusement to which this thread seeks to > solve and find answers to. They might not be all be the reasons, or perhaps > there is another reason altogether. > > Root of the question that either makes the question trivial, or very > important: > On one hand, it might just be that there hasn't been any code made yet for > this otherwise trivial exercise to change the virtual partition sizes. On the > other hand, it also gives the impression that Qubes is discouraging making > virtual partitions too big compared to the drive, for a good reason which > hasn't been easily explained to the masses. > > Afterthought: > The latter hand scenario is worrying, considering the very small 2GB home > folder partition size, when the technology of virtual partitions doesn't > appear to have an actual hard limit, as long as data doesn't exceed the soft > limit. Hence, should one be careful here? or is there really just another > less serious reason for the 2GB home folder partition size out-of-the-box? > For example Why isn't it just set to say, 100GB, or even 10.000GB by default, > if virtual partition sizes doesn't matter and most keep track of disk usage > in Dom0 anyway? > > I'm asking, since I'm considering to simply give each of my AppVM's the size > of my physical drive, and just keep track of the used drive space with > Dom0/XFCE4. > > If there are any reasons to be careful? or perhaps one should follow hard to > find guidelines to virtual partition sizes? > > It would be really appreciated to find a solid answer, or even just the best > answer available. > > > Cheers, > Yuraeitha > TL:DR. Why not just ask a simple question? Make them as large as you need them. Just use caution or you may run out of space. -- 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/or29l4%24dpa%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: System freezes several times a day
The entire system goes from "perfectly fine" to a state where the screen looks normal, but the sound gets stuck in a one second long loop and the system no longer responds to any keypres, the mouse doesn't react, it is completely 100% frozen. > > This happens several times a day now and turning off the power is the only > thing I can do. Reinstalling 3.2 from scratch didn't fix it. > I had temporary lockups that turned out to be related to a USB 3.0 (XHCI) controller and my USB mouse. Entire VMs would freeze until I switched to Dom0 and back, IIRC. I changed some settings in BIOS so everything was only EHCI and that fixed my problem. It may not be anything in Qubes; It may be memory errors or an overheating processor. Try running Memtest (freeware) for the memory. Check for and blow out any dust buildup in your computer. I don't know of an easy way to check temps within Qubes, but your BIOS ought to give some indication. -- 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/oqb51o%24mbh%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Hardened VM templates in Qubes
dhfgebenskzkwkwnd...@gmail.com: > Hello, please tell me if there are guides to hardening VM templates? > Coldhak.ca is dead, is there anything else or use KSPP manually? > > Thanks. > The Whonix wiki covers whonix-gw and whonix-ws. -- 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/b9e363ae-0afd-6943-b32d-8647bbf41894%40posteo.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Anyone disabled the Intel ME yet?
cooloutac: > On Sunday, September 24, 2017 at 8:24:44 PM UTC-4, cooloutac wrote: >> On Thursday, September 21, 2017 at 12:08:41 PM UTC-4, Hugo Costa wrote: >>> On Thursday, 21 September 2017 07:23:01 UTC+1, Alex wrote: Replying to this thread to report that somebody DID ACTUALLY find an exploitable vulnerability in the latest IME 11+, and they will be sharing nothing less that this UNSIGNED CODE EXECUTION vuln at blackhat europe 2017. Abstract here: https://www.blackhat.com/eu-17/briefings/schedule/#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine-8668 Title is pretty scary, but we'll see if it's actually that dangerous -- Alex >>> >>> Was going to post the same. 2 Russian researchers that a couple weeks ago >>> found out a way to clean some modules on Intel ME now have found a >>> significative exploit that allows them to actually run code on a piece of >>> hardware with direct access to the network. The scary thing is - it's >>> impossible to detect. >> >> and thats prolly just what we know about lol. > > I feel like cause I live in nyc that you just expect this type of stuff from > your friends and neighbors hahaha. maybe not the same means but the same > ends. but ya hardware level stuff is scary, cause that means real security > means alot of money, so poor people are screwed. > My motherboard has a "Disable ME" jumper. Not good enough for many of you, I know. As far as AMT, apparently the entry is through Intel NICs. I hoped to mitigate it by using a third party NIC. The Intel device stayed lit (amber, not green) on power off, my new one is completely off when powered off. -- 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/c6467dfa-2bb1-e0ec-8b3a-f433d228332a%40posteo.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Additional VPN destinations via CLI config?
qubester: > btw, how or why does one "check their MTU settings?" > Why? Incorrect MTU settings caused me to have disconnects from my VPN connections. After I measured and compensated for poor MTU, my connections have become much more stable and disconnects come back online shortly. How? MTU is essentially packet size. You can measure in CLI by pinging a server. There are a few tutorials to correct MTU in OpenVPN. Go to one of them to check it out. -- 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/3b7d163d-4d9b-c72a-e97b-cdfb9841b1a7%40posteo.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Best options for a 4.x compatible Dell workstation
Gaijin: > On 2017-09-12 05:32, pixel fairy wrote: >> On Monday, September 11, 2017 at 10:31:56 PM UTC-7, pixel fairy wrote: >>> given that appvms cant use 3d acceleration anyway, your best bet is intel >>> graphics. if your going to give a gpu to a vm, then it depends on the os of >>> that vm. >>> >>> last i checked, nvidia is fine with virtualization of quadro cards. >>> >>> make sure the workstation doesnt have AMT (vpro etc) as bussiness lines >>> tend to. you may be safer with what dell would otherwise sell as a consumer >>> desktop or gaming rig, minus the fancy graphics card unless your going to >>> use it. but, if thats a big part of your work, you may be better off with >>> linux + kvm or something else instead of qubes. >> >> damn nonlinear editing. that last sentence was supposed to go at the >> end of the first paragraph. > > Well, the good news is that enabling vPro on a Dell is an extra option > that you can select (costs $19), so I made sure that selection was off. > Thanks for the heads up. > > The newer Xeon chips in the E5 Series no longer include on-board > processor graphics, so Intel graphics isn't an option if I go this > route. They can handle a lot more RAM (1.2TB vs. 64GB) and have more > cores (10 vs. 4). There's generally a lot more I could do simultaneously > with this chip it seems looking at the specs. > > Researching through these forums and even the Qubes Docs there seems to > be a "stay away from nVidia" theme; That's why I was focusing on the AMD > graphics card option. Is nVidia Quadro a viable option? > > Using the Dell configurator, and plugging in RedHat Linux 7.2 as the OS > I find that the very newest AMD FirePro graphics card I selected isn't > compatible. (I'm assuming RHEL 7.2 is a roughly equivalent to the Fedora > 23 in dom0) So I dropped down to the older W5100 card and that seemed to > work for them. > > The graphics aren't really a big part of my work. I just want a box that > will be ready to run Qubes v4. > Gaijin: Intel GPU is recommended, AMD are second best. IIRC, Dom0 will be based on Fedora 25 in Qubes 4.0. Try checking AMD's site (https://support.amd.com/en-us/download) for compatibility reports, too. -- 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/op8l2q%24nh%242%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Best options for a 4.x compatible Dell workstation
Gaijin: > On 2017-09-12 05:32, pixel fairy wrote: >> On Monday, September 11, 2017 at 10:31:56 PM UTC-7, pixel fairy wrote: >>> given that appvms cant use 3d acceleration anyway, your best bet is intel >>> graphics. if your going to give a gpu to a vm, then it depends on the os of >>> that vm. >>> >>> last i checked, nvidia is fine with virtualization of quadro cards. >>> >>> make sure the workstation doesnt have AMT (vpro etc) as bussiness lines >>> tend to. you may be safer with what dell would otherwise sell as a consumer >>> desktop or gaming rig, minus the fancy graphics card unless your going to >>> use it. but, if thats a big part of your work, you may be better off with >>> linux + kvm or something else instead of qubes. >> >> damn nonlinear editing. that last sentence was supposed to go at the >> end of the first paragraph. > > Well, the good news is that enabling vPro on a Dell is an extra option > that you can select (costs $19), so I made sure that selection was off. > Thanks for the heads up. > > The newer Xeon chips in the E5 Series no longer include on-board > processor graphics, so Intel graphics isn't an option if I go this > route. They can handle a lot more RAM (1.2TB vs. 64GB) and have more > cores (10 vs. 4). There's generally a lot more I could do simultaneously > with this chip it seems looking at the specs. > > Researching through these forums and even the Qubes Docs there seems to > be a "stay away from nVidia" theme; That's why I was focusing on the AMD > graphics card option. Is nVidia Quadro a viable option? > > Using the Dell configurator, and plugging in RedHat Linux 7.2 as the OS > I find that the very newest AMD FirePro graphics card I selected isn't > compatible. (I'm assuming RHEL 7.2 is a roughly equivalent to the Fedora > 23 in dom0) So I dropped down to the older W5100 card and that seemed to > work for them. > > The graphics aren't really a big part of my work. I just want a box that > will be ready to run Qubes v4. > Gaijin: Intel GPU is recommended, AMD are second best. IIRC, Dom0 will be based on Fedora 25 in Qubes 4.0. Try checking AMD's site (https://support.amd.com/en-us/download) for compatibility reports, too. -- 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/550fc8e6-c049-132e-758e-4e403d3d697b%40posteo.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Additional VPN destinations via CLI config?
qubester: > On 09/11/2017 07:37 AM, > anguilla1980-re5jqeeqqe8avxtiumw...@public.gmane.org > wrote: >> I followed the tutorial here, specifically "Set up a ProxyVM as a VPN >> gateway using iptables and CLI scripts" >> >> https://www.qubes-os.org/doc/vpn/ >> >> I like having the iptables anti-leak rules. However, it's connecting >> automatically to my VPN providers destination that I downloaded their >> .ovpn for. >> >> Is it possible to compile multiple locations and be able to select >> which one? >> >> OR perhaps I'm going about this the wrong way? Should I instead use >> the GUI way via NetworkManager? Can I configure that for multiple >> destination choices then perhaps still add the iptables anti-leak rules? >> >> What's the best way? >> >> Thanks! >> > > na, just make another NetVM like you did for the one you got , or 2 3 > etc up to you , what i've been doing is after suspend just start the > new non active VPN NetVM and use it , after changing the appVMs using > it , bit tedious but works > Create a different VPN ProxyVM for each location you want to use. You lose leak protection if you use NetworkManager, you should use the iptables way. Once you get the first ProxyVM setup correctly, you can copy its files to other ProxyVMs to save time. Just verify their permissions and change the desired server in the .ovpn file. Check your MTU settings, too. -- 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/30d43377-7311-0970-7934-23594f9c006d%40posteo.de. For more options, visit https://groups.google.com/d/optout.
