On Mon, 2006-08-28 at 00:51 +0200, Nicolas "Ikke" Trangez wrote: > > If nothing else, we can likely make the assumption that if the user is > > requesting the device to NAT some internal network onto the internet, he > > trusts the internal network somewhat. The first two rules above with a > > warning might also be a good first stab. > > I dont think you can just say 'the user will trust the internal network'. I think > at least when starting network sharing, you should give a choice: open > up everything, or ask before allowing connections (MAC, or even better > hostname based, when possible to get this hostname. mdns might be > useful). > Might be usefull to only allow certain "safe" connections by default > too, like http/https, imap/imaps, ssh, ntp,... I dont think there's any > need to allow P2P and other applications by default. Agreed. Although, just to make sure we are on the same page, these restrictions are for outbound connections -- inbound connections to the internal nodes would be blocked anyway because of the NAT'ing. As for the restrictions themselves, I don't know whether NM is the best place to enforce firewalling of the internal network when it doesn't handle firewalling of the actual internet interface. IMHO, it makes more sense for NM to allow all outbound connections and let system-config-security or something (which does handle other firewalling needs) do the right thing for internal hosts. That said, if this were to be implemented, the actual security restrictions provided by NM are a secondary matter IMHO. Adding the NAT'ing/connection-sharing functionality would be more valuable -- even without enhanced security for the internal network, connection-sharing adds new functionality without compromising the security of the host running NM. 2c -- Saikat
Attachment:
signature.asc
Description: This is a digitally signed message part