Re: [qubes-users] Re: 4.0 rc1 firewall failed stderr cannot execute qrexec-daeomn
On 11.11.2017 13:43, David Hobach wrote: On 11/11/2017 12:52 AM, Stumpy wrote: On 10.11.2017 17:45, David Hobach wrote: On 11/10/2017 05:41 PM, David Hobach wrote: Your point about sys-net not working might very well be part of it as it seems to start sometimes and not others, though the firewall isn't starting 100% of the time. There's a few issues wrt the qubes firewall open on github. The funny/bad thing about it being that if it doesn't start, it'll default to "Allow all"... x_X That's present in 4.0rc2 at least. Correction: Just noticed that you were probably talking about the sys-firewall VM. I was talking about the qubes-firewall service running in sys-firewall. Well it seems that reinstalling didn't help. I tried w/o creating the whonix or usb sys templates, i didn't try the "advanced" option as I was not sure how to make templates and wasn't s motivated as to go that path. I did try the qvm-start route and wasn't able to start any of them, even when sys-net was up. A bit of a pity as I was looking forward to tinkering with it... and "learning how to stop worrying and love" Qubes w/o a VM Manager, I kinda liked the manager ;) Check the other threads on the topic (there were a couple about VMs not starting recently). Also try to set non-starting VMs to virt_mode = pv and try qvm-start again. That has some negative security implications (check Joannas thread on pv vs hvm virtualisation), but it might get them started at least. qvm-prefs sys-firewall virt_mode pv Ah well, will try later to upload (somehow) the journalctl outpt. Thx for the pv mode pointer, worked like a _charm_, much apprec. -- 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/414f2be8108f133099343cb4199cb4b6%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: 4.0 rc1 firewall failed stderr cannot execute qrexec-daeomn
On Saturday, November 11, 2017 at 1:40:24 PM UTC, Stumpy wrote: > On 11.11.2017 13:43, David Hobach wrote: > > On 11/11/2017 12:52 AM, Stumpy wrote: > >> > >> > >> On 10.11.2017 17:45, David Hobach wrote: > >>> On 11/10/2017 05:41 PM, David Hobach wrote: > > > Your point about sys-net not working might very well be part of it > > as it seems to start sometimes and not others, though the firewall > > isn't starting 100% of the time. > > There's a few issues wrt the qubes firewall open on github. The > funny/bad thing about it being that if it doesn't start, it'll > default to "Allow all"... x_X > > That's present in 4.0rc2 at least. > >>> > >>> Correction: > >>> Just noticed that you were probably talking about the sys-firewall > >>> VM. > >>> I was talking about the qubes-firewall service running in > >>> sys-firewall. > >> > >> Well it seems that reinstalling didn't help. I tried w/o creating the > >> whonix or usb sys templates, i didn't try the "advanced" option as I > >> was not sure how to make templates and wasn't s motivated as to go > >> that path. I did try the qvm-start route and wasn't able to > >> start any of them, even when sys-net was up. > >> A bit of a pity as I was looking forward to tinkering with it... and > >> "learning how to stop worrying and love" Qubes w/o a VM Manager, I > >> kinda liked the manager ;) > > > > Check the other threads on the topic (there were a couple about VMs > > not starting recently). > > > > Also try to set non-starting VMs to virt_mode = pv and try qvm-start > > again. That has some negative security implications (check Joannas > > thread on pv vs hvm virtualisation), but it might get them started at > > least. > > > > qvm-prefs sys-firewall virt_mode pv > > > > Thanks for the suggestions, while ultimately sec is important to me, for > this box I won't do anything important on it so this might be a > reasonable temp solution. Did switching to PV instead of HVM work for you btw? It's good to know for others reading this thread in the future. - - - - - At any rate, regardless of PV or HVM, Qubes is still really secure compared to most (all?) personal based OS systems for daily life. The HVM is an improvement up from Qubes 3.2, but Qubes 3.2 was still reasonably secure in its own right, in this day and age, compared to the rest of the OS's out there. Like it seems you think too, it indeed won't be the end of the world not having it. It's my understanding that the move towards HVM is to remove the kind of difficult to pull off PV attacks, which at current state certainly cannot be automated in any kind of malware either (I assume). Maybe a sophisticated futuristic A.I. or very dedicated (team of?) hackers with the right resources, can pull it off? Maybe someone more experienced can confirm if PV attacks are indeed rare or difficult to pull off, or if any such attack can be made easy, standardized or automated. Don't get me wrong, I'm not suggesting its meaningless to move to HVM, it just does not seem like the end of the world right now not to have it (unless someone else proves me wrong). Attacks toward PV might become easier in the future too, and early prevention is great, rather than being reactive or proactive. HVM might currently be more relevant for high profile targeted people using Qubes, whom need security. Or the "speculative" unlucky lot whom are the victims of skilled hackers out there trying to figure out how to hack Qubes (it's speculative how many or if any are trying to find exploits in Qubes on live systems in the wild, but rational to assume by the logic of deduction to be at least some hackers out there trying to attack live Qubes systems, it's a big world). So it becomes a question of how many skilled hackers who found a way to attack PV whom seek a live Qubes system to practice/learn on, vs. how many users whom actually use Qubes, and thereby, the odds/risk that you are among the unlucky few to get an successful attack. Seemingly, they should currently be rare and unconfirmed. -- 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/95925d74-8ed3-447b-b8cf-5f69901d5d5b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: 4.0 rc1 firewall failed stderr cannot execute qrexec-daeomn
On 11.11.2017 13:43, David Hobach wrote: On 11/11/2017 12:52 AM, Stumpy wrote: On 10.11.2017 17:45, David Hobach wrote: On 11/10/2017 05:41 PM, David Hobach wrote: Your point about sys-net not working might very well be part of it as it seems to start sometimes and not others, though the firewall isn't starting 100% of the time. There's a few issues wrt the qubes firewall open on github. The funny/bad thing about it being that if it doesn't start, it'll default to "Allow all"... x_X That's present in 4.0rc2 at least. Correction: Just noticed that you were probably talking about the sys-firewall VM. I was talking about the qubes-firewall service running in sys-firewall. Well it seems that reinstalling didn't help. I tried w/o creating the whonix or usb sys templates, i didn't try the "advanced" option as I was not sure how to make templates and wasn't s motivated as to go that path. I did try the qvm-start route and wasn't able to start any of them, even when sys-net was up. A bit of a pity as I was looking forward to tinkering with it... and "learning how to stop worrying and love" Qubes w/o a VM Manager, I kinda liked the manager ;) Check the other threads on the topic (there were a couple about VMs not starting recently). Also try to set non-starting VMs to virt_mode = pv and try qvm-start again. That has some negative security implications (check Joannas thread on pv vs hvm virtualisation), but it might get them started at least. qvm-prefs sys-firewall virt_mode pv Thanks for the suggestions, while ultimately sec is important to me, for this box I won't do anything important on it so this might be a reasonable temp solution. -- 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/4abedaff7638d65584ff8c06bed8966f%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: 4.0 rc1 firewall failed stderr cannot execute qrexec-daeomn
On 11/11/2017 12:52 AM, Stumpy wrote: On 10.11.2017 17:45, David Hobach wrote: On 11/10/2017 05:41 PM, David Hobach wrote: Your point about sys-net not working might very well be part of it as it seems to start sometimes and not others, though the firewall isn't starting 100% of the time. There's a few issues wrt the qubes firewall open on github. The funny/bad thing about it being that if it doesn't start, it'll default to "Allow all"... x_X That's present in 4.0rc2 at least. Correction: Just noticed that you were probably talking about the sys-firewall VM. I was talking about the qubes-firewall service running in sys-firewall. Well it seems that reinstalling didn't help. I tried w/o creating the whonix or usb sys templates, i didn't try the "advanced" option as I was not sure how to make templates and wasn't s motivated as to go that path. I did try the qvm-start route and wasn't able to start any of them, even when sys-net was up. A bit of a pity as I was looking forward to tinkering with it... and "learning how to stop worrying and love" Qubes w/o a VM Manager, I kinda liked the manager ;) Check the other threads on the topic (there were a couple about VMs not starting recently). Also try to set non-starting VMs to virt_mode = pv and try qvm-start again. That has some negative security implications (check Joannas thread on pv vs hvm virtualisation), but it might get them started at least. qvm-prefs sys-firewall virt_mode pv Ah well, will try later to upload (somehow) the journalctl outpt. -- 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/0a708222-ce48-dc78-93d5-47c2a0256d00%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] Re: 4.0 rc1 firewall failed stderr cannot execute qrexec-daeomn
On Friday, November 10, 2017 at 4:50:26 PM UTC, Stumpy wrote: > On 10.11.2017 17:45, David Hobach wrote: > > On 11/10/2017 05:41 PM, David Hobach wrote: > >> > >>> Your point about sys-net not working might very well be part of it as > >>> it seems to start sometimes and not others, though the firewall isn't > >>> starting 100% of the time. > >> > >> There's a few issues wrt the qubes firewall open on github. The > >> funny/bad thing about it being that if it doesn't start, it'll default > >> to "Allow all"... x_X > >> > >> That's present in 4.0rc2 at least. > > > > Correction: > > Just noticed that you were probably talking about the sys-firewall VM. > > I was talking about the qubes-firewall service running in > > sys-firewall. > > Ah well thanks anyway for that. I am reinstalling now and will see if I > can mess with the installation options in a way that might help resolve > this. Any thoughts on how I could fix the sys-firewall issue would of > course be nice. > > I also hope I can either get the network going or write something to a > flash so I can post the journalctl output (I am assuming that would be > helpful?) I recall briefly having tried Qubes RC-1 a good while back when it was first released, having similar issues to what you described. But with Qubes 4 RC-2 it went away. Chances are that it might just work when you get it up and running. Albeit there are still some other Qubes 4 RC-2 issues unresolved, at the very least, getting network to access the Qubes updates gives you a better survival chance. -- 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/3a0aff0d-af2a-4db3-bcdf-a32d3dbf8844%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: 4.0 rc1 firewall failed stderr cannot execute qrexec-daeomn
On 10.11.2017 17:45, David Hobach wrote: On 11/10/2017 05:41 PM, David Hobach wrote: Your point about sys-net not working might very well be part of it as it seems to start sometimes and not others, though the firewall isn't starting 100% of the time. There's a few issues wrt the qubes firewall open on github. The funny/bad thing about it being that if it doesn't start, it'll default to "Allow all"... x_X That's present in 4.0rc2 at least. Correction: Just noticed that you were probably talking about the sys-firewall VM. I was talking about the qubes-firewall service running in sys-firewall. Ah well thanks anyway for that. I am reinstalling now and will see if I can mess with the installation options in a way that might help resolve this. Any thoughts on how I could fix the sys-firewall issue would of course be nice. I also hope I can either get the network going or write something to a flash so I can post the journalctl output (I am assuming that would be helpful?) -- 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/a247d3a753c9ef711a6b6920fdeffd4e%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: 4.0 rc1 firewall failed stderr cannot execute qrexec-daeomn
On 11/10/2017 05:41 PM, David Hobach wrote: Your point about sys-net not working might very well be part of it as it seems to start sometimes and not others, though the firewall isn't starting 100% of the time. There's a few issues wrt the qubes firewall open on github. The funny/bad thing about it being that if it doesn't start, it'll default to "Allow all"... x_X That's present in 4.0rc2 at least. Correction: Just noticed that you were probably talking about the sys-firewall VM. I was talking about the qubes-firewall service running in sys-firewall. -- 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/189b4075-e5c5-f2bb-9d41-79009d6c13d9%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] Re: 4.0 rc1 firewall failed stderr cannot execute qrexec-daeomn
Your point about sys-net not working might very well be part of it as it seems to start sometimes and not others, though the firewall isn't starting 100% of the time. There's a few issues wrt the qubes firewall open on github. The funny/bad thing about it being that if it doesn't start, it'll default to "Allow all"... x_X That's present in 4.0rc2 at least. -- 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/6c173998-5c23-ae56-f926-3f211b81b1b2%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
[qubes-users] Re: 4.0 rc1 firewall failed stderr cannot execute qrexec-daeomn
On 10.11.2017 15:19, Stumpy wrote: Hi, I just tried installing rc1 on my computer and it went swimingly until I tried logging in at which point I got the error that was something like /usr/bin/qvm-start, firewall failed stderr cannot execute qrexec-daeomn I noticed on github that adrelanos has already posted about this bug and marmarek suggested trying qvm-start sysfirewall I tried that and it got: cannot execute qrexec daemon For what its worth I also tried to start the sys-usb so I could copy a file to usb and post it but got this error when I tried to start it: start failed: internal error: libxenlight failed to create new domain "sys-usb" marmarek also suggested looking at the output of sudo journalctl i put that into a txt file (700k+) but wasn't able to glean anythign from it. I wanted to post the file to the group, or pastebin, but as i mentioned I couldnt get usb-sys going, or any other vms really. sys-net starts up but as far as I can tell that is the only one, all the others don't start automatically or manually? How come you installed rc1? It's basically alpha release, in other words, extremely buggy and purely intended for testing purposes by the community. RC2 is technically what you could call beta release, which is potentially much more stable, but also not ready for final release. I assume you're talking about Qubes 4 RC-1 and not the now very old Qubes 3 RC-1. Try install Qubes 4 RC-2, and see if it works. Otherwise stick to Qubes 3.2. for now, which is much more stable. If you encounter python errors during the last stage Qubes 4 install, then re-install again, and try different configurations in the last install stage configuration. Also take note of this article https://www.qubes-os.org/news/2017/10/18/msi-support/ which was released between Qubes 4 RC-1 and Qubes 4 RC-2. Basically, this fix is not in the Qubes 4 RC-1, and it certainly is a fix that might affect your current problem. It's imho quite likely that your firewall won't start if sys-net is not working properly. For example if your sys-net is in HVM mode instead of PV mode, and you installed the Qubes RC-1 system without the PCI passthrough fixes. You need your network card properly passed through in sys-net VM before the firewall in sys-firewall VM can establish an internet connection. You'd want a system with working networking, otherwise you can't easily get the updates required to fix your alpha/beta release bugs and errors. Keep in mind, neither Qubes 4 RC-1 or Qubes RC-2 are stable releases, don't expect it work out of the box, the developers are still working on the final release. Alpha/Beta releases are for people who are support developers, community testers, or the curious souls. It's not meant for productivity or anything you'd expect of a stable system, unless, as some call it, that you are very brave. Ah cr*p, the 4.0rc1 was a bad case of my thinking one thing but typing another, I **promise** I am using rc2 I can certainly try reinstalling again, haven't tried that yet. I will say that I used all the default settings, opted to delete everything and install clean, etc Your point about sys-net not working might very well be part of it as it seems to start sometimes and not others, though the firewall isn't starting 100% of the time. As for the RC nature of 4.0 now, I am well aware of that and thought i'd try to install it for fun and post additional info that might help for debuging? Speaking of which, does the sys-usb have to be running to be able to use/mount a flash drive? anyway, I have 3.2 running nicely on my other box so I am not in dire straits :) -- 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/86930b475b9697f9cfce2b0402d1a50b%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: 4.0 rc1 firewall failed stderr cannot execute qrexec-daeomn
On Friday, November 10, 2017 at 2:20:02 PM UTC, Stumpy wrote: > Hi, I just tried installing rc1 on my computer and it went swimingly > until I tried logging in at which point I got the error that was > something like > /usr/bin/qvm-start, firewall failed stderr cannot execute qrexec-daeomn > I noticed on github that adrelanos has already posted about this bug and > marmarek suggested trying > qvm-start sysfirewall > I tried that and it got: > cannot execute qrexec daemon > For what its worth I also tried to start the sys-usb so I could copy a > file to usb and post it but got this error when I tried to start it: > start failed: internal error: libxenlight failed to create new domain > "sys-usb" > marmarek also suggested looking at the output of > sudo journalctl > i put that into a txt file (700k+) but wasn't able to glean anythign > from it. I wanted to post the file to the group, or pastebin, but as i > mentioned I couldnt get usb-sys going, or any other vms really. > sys-net starts up but as far as I can tell that is the only one, all the > others don't start automatically or manually? How come you installed rc1? It's basically alpha release, in other words, extremely buggy and purely intended for testing purposes by the community. RC2 is technically what you could call beta release, which is potentially much more stable, but also not ready for final release. I assume you're talking about Qubes 4 RC-1 and not the now very old Qubes 3 RC-1. Try install Qubes 4 RC-2, and see if it works. Otherwise stick to Qubes 3.2. for now, which is much more stable. If you encounter python errors during the last stage Qubes 4 install, then re-install again, and try different configurations in the last install stage configuration. Also take note of this article https://www.qubes-os.org/news/2017/10/18/msi-support/ which was released between Qubes 4 RC-1 and Qubes 4 RC-2. Basically, this fix is not in the Qubes 4 RC-1, and it certainly is a fix that might affect your current problem. It's imho quite likely that your firewall won't start if sys-net is not working properly. For example if your sys-net is in HVM mode instead of PV mode, and you installed the Qubes RC-1 system without the PCI passthrough fixes. You need your network card properly passed through in sys-net VM before the firewall in sys-firewall VM can establish an internet connection. You'd want a system with working networking, otherwise you can't easily get the updates required to fix your alpha/beta release bugs and errors. Keep in mind, neither Qubes 4 RC-1 or Qubes RC-2 are stable releases, don't expect it work out of the box, the developers are still working on the final release. Alpha/Beta releases are for people who are support developers, community testers, or the curious souls. It's not meant for productivity or anything you'd expect of a stable system, unless, as some call it, that you are very brave. -- 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/f483c625-c500-4e0f-89b7-0ac933bccd27%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
