I deeply thought that the very best idea that was ever proposed was network server project by @Rudd-o.
In its actual state, it lacks cascading to upstream AppVMs, but that implementation on 3.2 was actually permitting the Qubesos firewall GUI to define IN ports, having a visual way of seeing what is happening there. On February 18, 2021 12:27:33 AM UTC, "Marek Marczykowski-Górecki" <marma...@invisiblethingslab.com> wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >On Mon, Dec 28, 2020 at 11:50:56AM +0100, Giulio wrote: >> Hello everybody, although I understand it's a bit early, I've got a >> project idea for the 2021 GSoC. I plan to also apply to it as a student >> if it gets reviewed and approved, but that of course will come later. >> >> # Qubes GSoC 2021: Simplified external port forwarding and automatic NAT >> traversal >> ## Introduction >> Forwarding ports to Qubes VM is currently possible only though a multi >> step, error prone, manual process that also requires writing custom >> configuration in order to survive between reboots. >> Things as simple as starting a webserver or netcat for lan file sharing >> can be eventually a troublesome and time-wasting process[1][2]. > >Since some time there is an easier way: >https://www.qubes-os.org/doc/firewall/#opening-a-single-tcp-port-to-other-network-isolated-qube > >It isn't fully automatic, but _much_ easier than manual iptables rules. > >> Furthermore, applications that rely on NAT traversal protocols such as >> those for audio and video communications do not work in direct P2P mode >> with STUN and always use TURN instead[3]. >> >> ## Project goals >> Implement a GUI for automatic and persistent, eventually with a >> predefined timespan (ie: until reboot), port forwarding. The idea is to >> split horizontally the "Firewall Rules" tab in the "Qubes Settings" >> window and add another area below it. Add a checkbox to enable NAT >> traversal requests. When the checkbox is selected, the FirwallVM will >> redirect NAT traversal requests to a local python daemon or a dedicated >> VM that will negotiate the NAT traversal and configure the network >> accordingly. In this case, prompt the user in Dom0 about the NAT >> traversal request. Of course the qvm-* set of tools must e able to >> achieve the same tasks via CLI. > >While indeed appealing, this feature may be very easily abused to >unknowingly expose a VM to an extra attack surface. >At the very least there needs to be a way to a) see that some >connections are redirected into a VM and b) easy way to block them. >But to be honest, I'm not sure if this isn't too dangerous. Allowing a >VM to influence the firewall, even as a proposal for user to confirm >sounds risky. > >> ## Implementation >> Implementation will be discussed after the project idea is reviewed. >> >> ## Timeline >> Too early to plan, discuss implementation first. >> >> ## About me >> I'm a early adopter and long time QubesOS user. I've been using QubesOS >> ad my main operating systems for 5 years now. Although I've never >> contributed (yet) to the QubesOS source code, I've sometimes written >> about it[4]. >> Port forwarding is an issue that often arises in my daily usage, both >> for file sharing, tests, and in the field of security for serving >> payloads or receiving reverse shells. >> I will be graduating in March and I'm currently applying for some >> masters that will all eventually start on Semptember 2021. This will >> leave me with plenty of time for both working on the idea and then >> complete the task. >> I've already worked both privately and with my University with >> deadlines. I've a broad experience in python and in debugging problems >> in Qubes. >> In the past I've both done some security research and some personal >> projects, most of them can be found at [5]. >> >> [1] - https://github.com/QubesOS/qubes-issues/issues/3556 >> [2] - >> https://www.reddit.com/r/Qubes/comments/8cb57i/how_to_achieve_qube_to_qube_communication_port/ >> [3] - https://github.com/QubesOS/qubes-issues/issues/6225 >> [4] - https://git.lsd.cat/g/thinkpad-coreboot-qubes >> [5] - https://lsd.cat >> > >- -- >Best Regards, >Marek Marczykowski-Górecki >Invisible Things Lab >-----BEGIN PGP SIGNATURE----- > >iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmAttHQACgkQ24/THMrX >1yxAGwf/dLzur1FJApE4luGdOy9w4t9UWFas8yMNVZcE55iGo5j7fUz9zE5v2oYd >74GLec2npIrTQeF0YyLtFM7Qq37783tTPEcK0N0F4mFFackvyFf/5tYYK6tFTYBT >MMF4HhuNDRWcM6HOk2MObdro034gqo8hoELTUIWWN5/TVCksg1OJpQs3t+PflbEq >RIlgCpxBobQHfM47wuP1dkGE7DLFrm5fLUustYMNK0Upt/A+KKR2lGTRwtWD8CwX >sUffOJJswUSN8WCuteuD3DoqijEKO/B9YY8BGrJoPKFau9q775ywQqaTTfTgVKxG >Lr1Tm3huP0EaBS8Qdu8RUId7K0NEtw== >=1YVo >-----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 view this discussion on the web visit >https://groups.google.com/d/msgid/qubes-devel/YC20dXK%2BxXKUUx7n%40mail-itl. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/B40B6F69-7280-4F98-864A-0D006AF74DB5%40gmail.com.
