Re: RFE: Connection Sharing
On Sun, 2006-08-27 at 07:51 -0400, Saikat Guha wrote: > Would NM be the appropriate place to have "connection sharing" that just > works? Quite appropriate. This has been planned for a while, and blocks on multiple active devices, which in turn blocks on getting the last little bits of routing magic done in libnl, which Thomas Graf more or less promised to do last week. NetworkManager isn't in the business of doing firewall configuration though, and the best direction here is to get something like Firestarter D-Bus enabled so that anything that needs to modify firewall rules can request such modifications. Requests would be subject to standard D-Bus security restrictions and verification of course. David Zeuthen has written about this a lot in a couple of blog entries, which are somewhere here: http://davidz.fubar.dk . Dan > Provide bridging or NAT'ing to the interface connected. > > wi-fi to wired bridging: allow laptop connected to the net over wireless > to provide internet access to another laptop (or lan) connected through > a crossover cable (or wired switch). > > wired to wi-fi bridging: allow laptop connected to the net over a wired > network to act as an access-point for other wireless devices (either > ad-hoc mode or access-point mode depending on wireless driver support). > > NM would start a DHCP server on the subordinate interface, enable ip > forwarding, punch firewall rules to allow forwarded packets through, and > cleanup the above when sharing is stopped. > > thoughts? > ___ > NetworkManager-list mailing list > NetworkManager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFE: Connection Sharing
On Sun, 2006-08-27 at 20:35 -0400, Saikat Guha wrote: > 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. Not every distribution got a standard firewall-configuration management suite Nicolas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFE: Connection Sharing
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 signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFE: Connection Sharing
> If ethX is internet-facing and ethY is to be NAT'ed, perhaps > a rule at the very top of the iptables chain that whitelists all traffic > initiated from someone on ethY being routed to ethX should do the trick. > > iptables -I FORWARDING --in-interface ethY -j ACCEPT > iptables -t nat -I POSTROUTING --out-interface ethX -j ACCEPT Hmm. > > There is probably something more clever that can be done with marking > the packets and routing them through a separate table with greater > security for the box running NM from hostiles on the internal (ethY) > network. > > (vaguely from memory) > > ... --in-interface -j MARK 0x10 > ip ro add ... > > 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. Nicolas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFE: Connection Sharing
On Sun, 2006-08-27 at 20:42 +0200, Nicolas "Ikke" Trangez wrote: > On Sun, 2006-08-27 at 07:51 -0400, Saikat Guha wrote: > > Would NM be the appropriate place to have "connection sharing" that > > just > > works? > Having this functionality somewhere in the stack would be great, *but* > setting up NAT in iptables is very dependant on existring chains/rules > (where to put them etc). I don't know wether this is doable. I guess > flushing all chains is not an option ;-) If ethX is internet-facing and ethY is to be NAT'ed, perhaps a rule at the very top of the iptables chain that whitelists all traffic initiated from someone on ethY being routed to ethX should do the trick. iptables -I FORWARDING --in-interface ethY -j ACCEPT iptables -t nat -I POSTROUTING --out-interface ethX -j ACCEPT There is probably something more clever that can be done with marking the packets and routing them through a separate table with greater security for the box running NM from hostiles on the internal (ethY) network. (vaguely from memory) ... --in-interface -j MARK 0x10 ip ro add ... 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. -- Saikat signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFE: Connection Sharing
On 8/27/06, Saikat Guha <[EMAIL PROTECTED]> wrote: > Would NM be the appropriate place to have "connection sharing" that just > works? Possibly that would be up to the developers to decide but Firestarter claims to do this now if the functionality is required. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFE: Connection Sharing
On Sun, 2006-08-27 at 07:51 -0400, Saikat Guha wrote: > Would NM be the appropriate place to have "connection sharing" that > just > works? Having this functionality somewhere in the stack would be great, *but* setting up NAT in iptables is very dependant on existring chains/rules (where to put them etc). I don't know wether this is doable. I guess flushing all chains is not an option ;-) Nicolas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
