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.

> - 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.

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.

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.

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&return else sleep X"

Overall it's simply to fix in some of the possible ways.

>> 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.