Re: [qubes-users] Qubes 3.2: Temporarily allowing full access does not revoke it after the time runs out
I also just noticed that the feature seems to exist in the 4.0 GUI. Maybe I'll test that as well... I just tested it in 4.0 and that's affected by the bug as well... I managed to re-produce it 2/2 times with 2m and proxy and sys-net as netvm. What is interesting: qvm-firewall in dom0 lists a change (i.e. removes the "allow all" rule) after the timer runs out and even in the qubes-vm-settings GUI the checkbox is unchecked again, but the VM still has full Internet access... So whatever timer is there triggers, but the follow-up actions seem to be inappropriate. Btw in 4.0 "no access" seems to mean that DNS and ICMP is still allowed which seems somewhat weird, but at least it's mentioned in the GUI. So "no access" != "no network access" in 4.0. -- 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/7b495527-2b2e-4e20-5e24-a78daae3f924%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] Qubes 3.2: Temporarily allowing full access does not revoke it after the time runs out
On 02/04/2018 03:20 PM, David Hobach wrote: > Honestly I don't really understand why systemd was used at all for that > functionality. > > Anyway I did test your suggestion and unfortunately it didn't reliably > work for me: > 1/3 times it worked and that seemed to be the random chance of it > working that you also mentioned in your first bullet point. In fact I > followed your steps for 2m, tested it again after daemon-reload & it the > connection went through, then attempted 2 times after a reboot (the > service edit was still there) for which it worked once. When I was testing it I used OnActiveSec=20 and OnUnitActiveSec=20 for speed up debugging. I had "journal -f -u qubes-relaod-firewall@VM-name.timer/service". I experimented that behavior, with OnActiveSec alone the service was triggered once. With OnUnitActiveSec it worked as expected and it seems reliable. Did you get a failure test after adding OnUnitActiveSec? Did you ping same host before expiration or tried different one? > My 3.2 test machine was pretty outdated though, i.e. maybe it also > depends on the systemd version running. > > Feel free to update the ticket though. In particular the observation > that there is a certain chance for it to work as expected is rather > interesting. > > Whether or not an ongoing connection such as a continuing ping should be > broken after timeout is a different topic btw - I guess there's some > RELATED, ESTABLISHED iptables rule that keeps it up. > > I also just noticed that the feature seems to exist in the 4.0 GUI. > Maybe I'll test that as well... It would be nice to found a fix for this but it should only break non-explicitly allowed connections? It seems pretty complex. > In total however using sth like > qvm-firewall [allow all] && sleep [time] ; qvm-firewall [remove allow all] > currently seems to be more reliable. > Totally agree, using systemd for this seems pretty overcomplex. Maybe using sleep could lead some problems with suspend/resume. Another option would be "while true if expiration then update else sleep X" Overall it's simply to fix in some of the possible ways. -- 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/0d713d27-d620-0fa0-ccab-b0c9ad4993dd%40riseup.net. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Qubes 3.2: Temporarily allowing full access does not revoke it after the time runs out
On 02/03/2018 01:31 PM, donoban wrote: On 02/03/2018 01:10 PM, David Hobach wrote: When you add temporary access for a AppVM, a service and a timer are created for that VM: - qubes-reload-firewall@(VM-Name).timer - qubes-reload-firewall@(VM-Name).service then the timer is enabled. 1min later the timer is fired and it enables the service, the service checks if the rule has expired and if yes it updates the iptables rules and stops the timer. The problem without "OnUnitActiveSec=1m" is that the timer is not fired anymore (at least on my computer), it goes to "elapsed" state, and the service is not enabled never again and the VM still with full access forever. Maybe is some problem with systemd. I am not sure about the desired effect of OnActiveSec alone. Honestly I don't really understand why systemd was used at all for that functionality. Anyway I did test your suggestion and unfortunately it didn't reliably work for me: 1/3 times it worked and that seemed to be the random chance of it working that you also mentioned in your first bullet point. In fact I followed your steps for 2m, tested it again after daemon-reload & it the connection went through, then attempted 2 times after a reboot (the service edit was still there) for which it worked once. My 3.2 test machine was pretty outdated though, i.e. maybe it also depends on the systemd version running. Feel free to update the ticket though. In particular the observation that there is a certain chance for it to work as expected is rather interesting. Whether or not an ongoing connection such as a continuing ping should be broken after timeout is a different topic btw - I guess there's some RELATED, ESTABLISHED iptables rule that keeps it up. I also just noticed that the feature seems to exist in the 4.0 GUI. Maybe I'll test that as well... In total however using sth like qvm-firewall [allow all] && sleep [time] ; qvm-firewall [remove allow all] currently seems to be more reliable. -- 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/57292981-35a3-07ea-3f22-33231140f54e%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] Qubes 3.2: Temporarily allowing full access does not revoke it after the time runs out
For clarify: On 02/03/2018 01:10 PM, David Hobach wrote: >> - open in dom0: /usr/lib/systemd/system/qubes-reload-firewall@.timer >> and add "OnUnitActiveSec=1m" on the end of file. >> >> >> - Reload systemd config -> "systemctl daemon-reload" and try to test >> again. > > Doesn't changing the config and reloading all services with changed > config just reload the firewall service? Probably not, "systemctl daeemon-reload" just reloads the configuration of the units, I think it doesn't reload any service. > Then of course the iptables rules are re-generated taking the expired > timer into account. So basically you're just doing a manual reload > because the automatic didn't trigger or work when it should have? > I am not doing a manual reload of the service, I am changing the behavior of qubes-reload-firewall@.timer because without my modification it does not work as expected. It fires only once and if the full access is not expired it will not check again. -- 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/7f5bad57-fb23-866c-24fe-18ed69193e9c%40riseup.net. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Qubes 3.2: Temporarily allowing full access does not revoke it after the time runs out
On 02/03/2018 01:10 PM, David Hobach wrote: >> - open in dom0: /usr/lib/systemd/system/qubes-reload-firewall@.timer >> and add "OnUnitActiveSec=1m" on the end of file. >> >> >> - Reload systemd config -> "systemctl daemon-reload" and try to test >> again. > > Doesn't changing the config and reloading all services with changed > config just reload the firewall service? > > Then of course the iptables rules are re-generated taking the expired > timer into account. So basically you're just doing a manual reload > because the automatic didn't trigger or work when it should have? > > I didn't test it though, just my guesses from reading your proposal. When you add temporary access for a AppVM, a service and a timer are created for that VM: - qubes-reload-firewall@(VM-Name).timer - qubes-reload-firewall@(VM-Name).service then the timer is enabled. 1min later the timer is fired and it enables the service, the service checks if the rule has expired and if yes it updates the iptables rules and stops the timer. The problem without "OnUnitActiveSec=1m" is that the timer is not fired anymore (at least on my computer), it goes to "elapsed" state, and the service is not enabled never again and the VM still with full access forever. Maybe is some problem with systemd. I am not sure about the desired effect of OnActiveSec alone. If you test it first maybe the timer it's already in elapsed state and the fix doesn't work without manually stopping it. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To 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/ba2b684a-ff1e-fe2b-3215-924b4aa2bc14%40riseup.net. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Qubes 3.2: Temporarily allowing full access does not revoke it after the time runs out
- open in dom0: /usr/lib/systemd/system/qubes-reload-firewall@.timer and add "OnUnitActiveSec=1m" on the end of file. - Reload systemd config -> "systemctl daemon-reload" and try to test again. Doesn't changing the config and reloading all services with changed config just reload the firewall service? Then of course the iptables rules are re-generated taking the expired timer into account. So basically you're just doing a manual reload because the automatic didn't trigger or work when it should have? I didn't test it though, just my guesses from reading your proposal. -- 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/0a4767dd-0683-c55a-47d2-2585749c443a%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
[qubes-users] Qubes 3.2: Temporarily allowing full access does not revoke it after the time runs out
Hi, Some days ago I decided to investigate this issue: https://github.com/QubesOS/qubes-issues/issues/1173 I think that I found the solution, at least it seems working fine for me. If some dev could take a look, it's very simple to check and fix and if you are considering a new 3.2 release would be nice to include this fixed. If someone want to test: - Add a temporary full access to some AppVM (use at least 2min for expiration, with 1min is very likely it appears to work fine) - Wait the expiration time and then check if the AppVM has full access to Internet. If yes your are affected by the bug. - open in dom0: /usr/lib/systemd/system/qubes-reload-firewall@.timer and add "OnUnitActiveSec=1m" on the end of file. - Reload systemd config -> "systemctl daemon-reload" and try to test again. -- 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/99d113b6-1e51-7cf2-d0e2-e6404c61cdd6%40riseup.net. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature