Harden Network

[monsieuremre]

I am not sure if this package would be the right place for this task, but I think there is no other kicksecure repo that is more suited.

We have to take upon ourselves to harden the interaction with network. This has several steps:

• Set up a really hardened firewall using nftables. Alternatively we can depend on a high level firewall service.
• Block all incoming connections.
• Block all forwarding and routing.
• Allow forwarding and routing and incoming connections for a few select network daemons and applications, like cups, ssh, avahi etc., so that the average user won't notice a thing at all.
• For all the select daemons that are allowed to bypass the firewall, set the environment variable Environment="LD_PRELOAD='libhardened_malloc.so' in their systemd service config.
• Also for those, set After=apparmor.service and AppArmorProfile=profile.
• Profiles will be from apparmor.d, which I am hoping kicksecure will package soon, because it is really already ready and there is a deb target specifically for whonix upstream. We would have to depend on this package, which I think is ok. We should not be afraid to depend on packages, especially those that belong to kicksecure.
• We would also have to depend on hardened malloc as you can guess.

What is achieved after: No connection from outside can enter the system aside from select services, which are forcibly protected and heavily limited and confined with mandatory access control and significantly hardened against memory and heap safety vulnurabilities. This won't be suited for servers. About that I am opening another issue.

[adrelanos]

• Set up a really hardened firewall using nftables. Alternatively we can depend on a high level firewall service.
• Block all incoming connections.
• Block all forwarding and routing.

A firewall seems quite too much for security-misc. Kicksecure firewall should go:

• into a new, dedicated package: kicksecure-firewall
• or maybe mix into existing package kicksecure-network-conf

not sure yet.

Some related off-topic discussion here:
#187 (comment)

• Allow forwarding and routing and incoming connections for a few select network daemons and applications, like cups, ssh, avahi etc., so that the average user won't notice a thing at all.

For desktop it seems hard to reason about which ones to enable by default and which ones to prohibit. avahi not sure how important that is for actual users. cups works fine for local printing even if a firewall is enabled. Printing over network is rare and in that case opening a port in the firewall can be required. That's a usability regression over Debian but a well justified one and there would be documentation how to easily open any port.

By having zero open ports by default, it's a bit more secure. Less fingerprinting can be done by scanners. But if at least 1 port is open, more information can be gathered.

• For all the select daemons that are allowed to bypass the firewall, set the environment variable Environment="LD_PRELOAD='libhardened_malloc.so' in their systemd service config.

I'd rather solve the issues preventing hardened malloc enabled by default than having a ton of different mechanisms (for suid, for daemons) for opt-in hardened malloc.

• Also for those, set After=apparmor.service and AppArmorProfile=profile.

Probably a non-issue. This should already implicitly be the same thanks to systemd targets. Systemd is quite clever about this and distributions inhert this. If you find any daemons that load before AppArmor, please report the issue upstream and link the bug report here.

• Profiles will be from apparmor.d, which I am hoping kicksecure will package soon, because it is really already ready and there is a deb target specifically for whonix upstream. We would have to depend on this package, which I think is ok. We should not be afraid to depend on packages, especially those that belong to kicksecure.

• We would also have to depend on hardened malloc as you can guess.

• Depends: in security-misc: No, as per Depends: vs Recommends: vs none #169
• Depends: in kicksecure-meta-packages: Potentially, yes.

This won't be suited for servers.

This is a problem because kicksecure-meta-packages doesn't really have server and desktop packages yet. That needs some work.