Re: [qubes-devel] qubes-firewall script error handling
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. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/b728315b-85f2-a380-06c1-33df47737d65%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] qubes-firewall script error handling
On Monday, February 19, 2018 at 12:30:52 AM UTC+1, 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. > > 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- 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? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/df60091e-7ba4-4a09-91ed-bed55e9566a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] qubes-firewall script error handling
-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- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180218233019.GT2084%40mail-itl. For more options, visit https://groups.google.com/d/optout.
