Evgeniy Polyakov <[EMAIL PROTECTED]> writes: > On Mon, Oct 02, 2006 at 08:11:06AM +0200, Samir Bellabes ([EMAIL PROTECTED]) > wrote: >> >> This patch adds a connector which reports networking's events to >> userspace. It's sending events when a sock has its sk_state changed to : >> - LISTEN or CLOSE for DCCP and TCP >> - BIND or CLOSE for UDP. >> >> With this notification, a userspace tool can ask the user if he want to >> let the local firewall open for the corresponding sport or not, and if >> so open the firewall for the application which get the corresponding sport. >> >> For people behind a firewall (non-running in the user box) we can have a >> authentification between the user box, which have set the port to state >> TCP_LISTEN for example, and the firewall, in a such way that the >> firewall's router will forward incoming packet for this port to the user >> box. >> >> It will avoid adding specific rules to the user's firewall-script, and >> let the firewall be more interactive for users. >> >> Signed-off-by: Samir Bellabes <[EMAIL PROTECTED]> > > Interesting... Mybe it even prints the name of the application which is > trying to change port state?
Yes, of course, the name of the application is a part of the 'trusted system'. But i think we can look for the application which gets the inode corresponding to the sock in userspace, using the /proc/<pid> files. Whithout this, we have to lookup all the process in kernel, in order to find the one which old the sock. It's time consumming, even if the kind of event involved (listening/close port) doesn't occur so often. But if you think the kernel can do that, it's not a problem, i have code to do that. In fact the '$PATH/apps' is the complete info we need. With it, we can ask the user, and we can check with the 'distro' tools (urpmi, apt-get, smart) if the '$PATH/apps' really belongs to the distro and should be trust. I'm working also in a option on this, in order to avoid some 'false positive', because some ports don't need to be 'open' in the firewall, using conntrack. As a example, you can take ftp's client, which will own a listening port when it will received data from server, but the ip/nf_conntrack_ftp will do the jobs for us, in order to let the data coming in. This current patch will send the information that the ftp's client is listening on a port (and a userspace tool will ask the user about what to do with this) but the ip_conntrack as already did the job. > I have couple of comments about structures you use, otherwise it looks > good, although I do not know if it is ok or not ok to include it into > mainline tree. > From one point of view it is small and interesting piece of code, from other > point it is not clear if such functionality is needed... ok. > Btw, you could also create netlink/connector based firewall rules > update, I think people with hundreds of rules in one table will bless > you after that. This is the real goal, using ipset - http://ipset.netfilter.org/ With this we can easily create a uniq rule for iptables, and then add/remove port from the 'set' involve. >> +#ifndef CN_NET_H >> +#define CN_NET_H >> + >> +#include <linux/time.h> >> +#include <linux/ipv6.h> >> + >> +/* >> + * Userspace sends this enum to register with the kernel that it is >> listening >> + * for events on the connector. >> + */ >> +enum cn_net_status { >> + CN_NET_LISTEN = 1, >> + CN_NET_IGNORE = 2 >> +}; >> + >> +struct net_event { >> + enum event { >> + NET_EVENT_NONE = 0x00000000, >> + NET_EVENT_TCP_LISTEN = 0x00000001, >> + NET_EVENT_TCP_CLOSE = 0x00000002, >> + NET_EVENT_UDP_BIND = 0x00000004, >> + NET_EVENT_UDP_CLOSE = 0x00000008, >> + NET_EVENT_DCCP_LISTEN = 0x00000010, >> + NET_EVENT_DCCP_CLOSE = 0x00000020, >> + NET_EVENT_MAX = 0x80000000 >> + } event; >> + struct timespec timestamp; > > Doesn't this monster have different size in 64 and 32 bit > environments? I see. >> + union { >> + struct { >> + __u32 err; >> + } ack; >> + >> + struct { >> + unsigned int family; >> + union { >> + struct in6_addr ipv6; >> + unsigned long ipv4; > > Please no longs in code which is supposed to be used simultaneously in > 32 and 64 bit environments. Of course. Thanks for you comments, i will send a new patch later today. regars. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
