IP forwarding is on while qubes-firewall starts

[Chris Laprise]

A departure from the R3.x behavior that I think may compromise network
security is that in R4.0 proxyVMs /proc/sys/net/ipv4/ip_forward is '1'
while qubes-firewall is starting and executing firewall scripts.

Unless there is some detail that makes ip_forward moot, I think there
should be a patch (ex: /etc/sysctl.conf) to have the initial VM
forwarding state at '0' until qubes-firewall finishes initializing.

--

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 Thu, Apr 19, 2018 at 08:29:17PM -0400, Chris Laprise wrote:
> A departure from the R3.x behavior that I think may compromise network
> security is that in R4.0 proxyVMs /proc/sys/net/ipv4/ip_forward is '1' while
> qubes-firewall is starting and executing firewall scripts.
>
> Unless there is some detail that makes ip_forward moot, I think there should
> be a patch (ex: /etc/sysctl.conf) to have the initial VM forwarding state at
> '0' until qubes-firewall finishes initializing.

There is already service ordering that make qubes-firewall starting
before qubes-network (which enables ip_forward). The first thing that
qubes-firewall service does is insert default DROP rule into appropriate
forward table. But indeed there is nothing that guarantee that
ip_forward is enabled only after calling user script.

Also note that thanks to atomic updates (nftables, iptables-restore), ip
forwarding is no longer disabled for the time rules are reloaded. But
also thanks to using separate chains, user rules don't need to be
re-created each time.

- --
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/THMrX1ywFAlrZPiMACgkQ24/THMrX
1yzr6Af/ZyqVFVV2aoEDvLsoPI51RaXaWeNEfVKpQ/A6dkENtxgGTCkRWGSIl4v3
VMjLPMFCrULNlQhlGcYOtcRBCWW25bgHvvQPRR+TnL/XXmZGN/xmYc+qOKJltUDp
ht4u8sJdybf/vXs8jdnxjv0S/JpXgjgBLF1XaNpLWdg7cVC7RMYIOjwieXkkDuIM
wk/DINKAQLO2+4ppqpcUJ3iiBOLEzZeaaRjsMhTpjazewRYeFXkP2c2kC8rO4dJD
EakFcDYxDDVemW4vAbpAe9dw/iuJYIFCEet30FWv0sg0JmofY4UokHxt09fj3Zlp
iOnBn3O2JuljnJLUmuGXUtDZkMUMog==
=6KFc
-----END PGP SIGNATURE-----

[Chris Laprise]

On 04/19/2018 09:10 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Thu, Apr 19, 2018 at 08:29:17PM -0400, Chris Laprise wrote:
>> A departure from the R3.x behavior that I think may compromise network
>> security is that in R4.0 proxyVMs /proc/sys/net/ipv4/ip_forward is '1' while
>> qubes-firewall is starting and executing firewall scripts.
>>
>> Unless there is some detail that makes ip_forward moot, I think there should
>> be a patch (ex: /etc/sysctl.conf) to have the initial VM forwarding state at
>> '0' until qubes-firewall finishes initializing.
>
> There is already service ordering that make qubes-firewall starting
> before qubes-network (which enables ip_forward). The first thing that
> qubes-firewall service does is insert default DROP rule into appropriate
> forward table. But indeed there is nothing that guarantee that
> ip_forward is enabled only after calling user script.

If qubes-network enables ip_forward later, its likely that something
else prior to that (and qubes-firewall) is also enabling it.

A qubes-firewall.d script of 'cat /proc/sys/net/ipv4/ip_forward
>/somefile' shows the value == 1.

OTOH, if eth0 interface is not up at the point (not sure on that point)
then it may not matter.

>
> Also note that thanks to atomic updates (nftables, iptables-restore), ip
> forwarding is no longer disabled for the time rules are reloaded. But
> also thanks to using separate chains, user rules don't need to be
> re-created each time.

[Chris Laprise]

BTW another test from qubes-firewall.d shows that eth0 is 'UP' at that time.

[Chris Laprise]

Clarification: eth0 is UP, but not vif+.

[Marek Marczykowski-Górecki]

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

On Thu, Apr 19, 2018 at 11:00:58PM -0400, Chris Laprise wrote:
> On 04/19/2018 10:59 PM, Chris Laprise wrote:
> > On 04/19/2018 10:54 PM, Chris Laprise wrote:
> > > On 04/19/2018 09:10 PM, Marek Marczykowski-Górecki wrote:
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA256
> > > >
> > > > On Thu, Apr 19, 2018 at 08:29:17PM -0400, Chris Laprise wrote:
> > > > > A departure from the R3.x behavior that I think may compromise network
> > > > > security is that in R4.0 proxyVMs
> > > > > /proc/sys/net/ipv4/ip_forward is '1' while
> > > > > qubes-firewall is starting and executing firewall scripts.
> > > > >
> > > > > Unless there is some detail that makes ip_forward moot, I
> > > > > think there should
> > > > > be a patch (ex: /etc/sysctl.conf) to have the initial VM
> > > > > forwarding state at
> > > > > '0' until qubes-firewall finishes initializing.
> > > >
> > > > There is already service ordering that make qubes-firewall starting
> > > > before qubes-network (which enables ip_forward). The first thing that
> > > > qubes-firewall service does is insert default DROP rule into appropriate
> > > > forward table. But indeed there is nothing that guarantee that
> > > > ip_forward is enabled only after calling user script.

Implemented:
https://github.com/QubesOS/qubes-core-agent-linux/commit/f6dc28106b6153aa0c3b302afe7872e8b3820104

> > > If qubes-network enables ip_forward later, its likely that something
> > > else prior to that (and qubes-firewall) is also enabling it.
> > >
> > > A qubes-firewall.d script of 'cat /proc/sys/net/ipv4/ip_forward
> > >  >/somefile' shows the value == 1.
> > >
> > > OTOH, if eth0 interface is not up at the point (not sure on that
> > > point) then it may not matter.
> >
> > BTW another test from qubes-firewall.d shows that eth0 is 'UP' at that
> > time.
>
> Clarification: eth0 is UP, but not vif+.

- --
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/THMrX1ywFAlrZ/uMACgkQ24/THMrX
1ywolgf+PXkhJ1rGjXbN9oYbQ4P3Vu9J68xBDCPiOxZLi5kH20P8plOjz/d/VAAx
AhkI+dV6+xUIZMcsOfYoHlS6kRrq47umPAn5LnS5+Sp/hJtt7tDKqvxUzgMEbUy7
Zn+nWElnwMtgB/yN7Ogs+6Flt7RM7BJ6lsRvMIhQA0B9aXbZfxPtWELmnSbwbBj5
g9QXjmSD9lAPnx5uljX7qXE2w57UUS9xNa16r3k3SkzTGI3tNkH0D99JrbziXzt9
c7hAbeBjRoJbeRsBZO4+5qFMa5F7qVH6kd9oifn/dPnHkvWFhtoDFy1it60HL4yO
w783t7lePLyMJL5AogT3kAFbXs5KiQ==
=Ayv3
-----END PGP SIGNATURE-----