In <alpine.LSU.2.00.0905062048470.2211@nimrodel.valinor>, Carlos E. R. wrote:
On Tuesday, 2009-05-05 at 22:47 -0500, Rajko M. wrote:
It seems that you never used personal firewall in that other OS, at least not paid for version. User is asked would he let application [name] to access Internet, with offer to give more details if user wants. So, if you see some application attempting to access Internet, and you are not sure, you click link to more information and read what firewall creators have to say.
That situation is impossible in Linux, as the firewall can not track to which application belongs a network packet. The only info available is "this packet on that port was rejected" (past tense), but the application responsible is unknown.
Not entirely. Check out the "owner" iptables module. Packets originating from the local userspace do have an owner. That module can only match on a uid or gid, but it could conceivably be extended so that a pid could be attached. Now, it would probably have to be the pid that opened the socket, which may not be the pid that did the last write to the socket, but I believe that same limitation applies to the uid/gid match that already exists. Yes, any extension in this direction probably requires a kernel patch, but that is not necessarily a bad thing. It might also break the ULOG ABI (or equiv.) which could be very unfortunate--the old interface would probably need to be maintained for many years along-side the new interface--but if there is enough effort applied even mountains can be moved.[1]
Further, the firewall closes ports to incoming packets from the outside, not to outgoing packets, and there is no info to link this to whatever application might have opened that port for listening. The two things, opened port by and app and firewall are disconnected in Linux.
Actually, the Linux firewall affects packets in 5 stages, although an individual packet will only hit 3 of those stages. It can very well affect outgoing connections on the PREROUTING, OUTPUT, or POSTROUTING chains.
Therefore, it is not possible to pop up a window saying that a certain app requests a port to be opened. The port has in fact already being opened, but packets are rejected by the firewall, who has no information about which program might or might not need that rejected packed, and thus can not give that info on the popup window to help in the decision.
Assuming we get over the problem of not having the "pid" in the information provided via ULOG, we do have the protocol and (if the protocol uses them) source and destination port numbers. It is quite possible for the application getting the ULOG information to raise a popup, and then alter a user-defined chain. Something like this in the output chain might work some day (but it would require enhancements to Linux at all levels): --jump-formatted 'user_whitelisted_ports-%uid-%pid' -j ULOG 'desktop_firewall_notifier' -j REJECT -j DROP desktop-firewall-notifier could be responsible for the popup, and adding rules to the appropriate user_whitelisted_ports-* chain to accept packets. It, or another daemon, would be responsible for persisting user preferences, and deleting chains when the user logs out or the process terminates. It isn't possible today. It isn't something *I* want to work on. It will require a lot of work. Perhaps it might even make Linux better. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ [1] If you are interested in this, get ready to provide code or hire someone to provide code. When we speak of Free Software, we mean freedom not price.