qubes-firewall script error handling

[Chris Laprise]

I'm thinking about posting a PR to have qubes-firewall raise errors
whenever a firewall script from qubes-firewall-user-script or
qubes-firewall.d returns an error code.

The object is to provide a way to make the qubes-firewall service fail
when firewall scripts encounter an error. On failure, the result would
be that forwarding (or networking) is disabled and any units bound to
qubes-firewall would not run.

Default behavior would be little different than it is now, given that
shell scripts are fault-tolerant. But script authors will have the
option of using "set -e" or "exit 1" etc. so the service goes into a
failed state.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Feb 18, 2018 at 01:10:44PM -0500, Chris Laprise wrote:
> I'm thinking about posting a PR to have qubes-firewall raise errors whenever
> a firewall script from qubes-firewall-user-script or qubes-firewall.d
> returns an error code.
>
> The object is to provide a way to make the qubes-firewall service fail when
> firewall scripts encounter an error. On failure, the result would be that
> forwarding (or networking) is disabled and any units bound to qubes-firewall
> would not run.
>
> Default behavior would be little different than it is now, given that shell
> scripts are fault-tolerant. But script authors will have the option of using
> "set -e" or "exit 1" etc. so the service goes into a failed state.

Problems like crashed qubes-firewall are very annoying and it isn't easy
to find where such service have crashed. Also, script exiting with
non-zero code can happen for various reasons, including misusing "[
condition ] && action" syntax. I've seen far to many errors like that.

But if the script author know what he/she is doing, having option to
fail closed is a good idea. What about choosing en exit code that would
cause the effect you propose? And let that not be 1. This could allow
both: fail closed for conscious user, and harder to break the setup by
stupid error. The idea is inspired by Restart*ExitStatus= settings of
systemd.service and git bisect run.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqKDIMACgkQ24/THMrX
1yxJKwf9FKb4Cl9aB1uW14PH1+O2G/6vfs0cDjLfcaxt6Rx6j58sotKflwhvL6l/
XcQx/jorAqp+3NyH4+4Y4JK6cEVgind+EAP5PQ16PFKuLkV5UwrGvR6HBXAKzcf5
i+tIXumYYPJ+rUXbkXccCRIddHcjLnViiWjOHwU9nPg3UTDi0/5om2wOTJPw3ciA
8vCG78iJBnAWPFM8nx47pJMClbQUiyvm/FRq9lnWdasDuf3Edb10QaYHWf+1x9Sq
ptgjryQduGmvZpgxWA/O6m7b4AvawrIuH3gWAk6ssBzT3+LSgfCQHG48QMJnaOie
urmNZhh8cXmiHa/hfty2d9ZsnEIDkw==
=RXyO
-----END PGP SIGNATURE-----

[Yuraeitha]

What are the prospects of using multiple of firewalls on Qubes, if the intention is to run something that is "unique", or if VM's talk to each others, or if hosting a server on Qubes? Each of these, representing a need for a seperate firewall.

Would this be useful from a security point of view? For example I've always wanted to host a mini-server on my Qubes laptop, but I'm worried modifying the firewall can cause system-wide issues that can be exploited, or just flat out cause errors like the ones mentioned here.

As such, in terms of having a default firewall for non-changed Qubes, and a modified firewall for special modifications? Kind of like everything else in Qubes work by not having a single point of failure.

Would this be feasible? and would it make errors less likely to happen in the default firewall, if special use-cases are kept on seperate firewall AppVM's?

[Chris Laprise]

On 02/18/2018 06:30 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Sun, Feb 18, 2018 at 01:10:44PM -0500, Chris Laprise wrote:
>> I'm thinking about posting a PR to have qubes-firewall raise errors whenever
>> a firewall script from qubes-firewall-user-script or qubes-firewall.d
>> returns an error code.
>>
>> The object is to provide a way to make the qubes-firewall service fail when
>> firewall scripts encounter an error. On failure, the result would be that
>> forwarding (or networking) is disabled and any units bound to qubes-firewall
>> would not run.
>>
>> Default behavior would be little different than it is now, given that shell
>> scripts are fault-tolerant. But script authors will have the option of using
>> "set -e" or "exit 1" etc. so the service goes into a failed state.
>
> Problems like crashed qubes-firewall are very annoying and it isn't easy
> to find where such service have crashed. Also, script exiting with
> non-zero code can happen for various reasons, including misusing "[
> condition ] && action" syntax. I've seen far to many errors like that.

The intention is for a script author who wants net enabled only if
firewall script runs exactly right... they can use "set -e". Otherwise
the service wouldn't be affected by an error.

As for finding errors when they occur, looking at journalctl is pretty
informative since related lines about failure are highlighted and twice
mention the method i.e. "self.run_user_script". I was wondering if the
service could also do a notify-send, or even call a qubes-rpc method
that merely informs about VM state in such a case.

Alternately, instead of failing the service could handle the error by
simply logging it and disabling forwarding for the proxyVM. Another
service (post-misc?) might display an informational popup about
forwarding state.

>
> But if the script author know what he/she is doing, having option to
> fail closed is a good idea. What about choosing en exit code that would
> cause the effect you propose? And let that not be 1. This could allow
> both: fail closed for conscious user, and harder to break the setup by
> stupid error. The idea is inspired by Restart*ExitStatus= settings of
> systemd.service and git bisect run.

I think this would put a burden on the script writer to improvise (and
not accidentally undermine) their own facsimile of try/catch so that
sending the special exit code is possible. In this case, the script
writer has already done (precariously) 95% of what is needed to prevent
the proxyvm from going online anyway. IOW

I'm asking about this because I started to put checks for firewall rules
in the qubes-tunnel startup code, but it seems kludgey to have a
non-firewall script check for specific rules. Its cleaner to just
enforce error checking in the first place.

-

Also... looking at how qubes-firewall fails at that point, its different
than the 3.2 behavior I remember where enabling of forwarding followed
in sequence after the user script. When the R4.0 service fails at
run_user_script the system continues with forwarding enabled which seems
suboptimal.