Andi Kleen: >> ... and then do the same for the first TCP packet with payload? And you > > That gets passed through by the firewall rule. > As an application developer, I find it very common for our users to have difficulty synchronizing userspace program needs and firewall rules. This option would greatly enable hiding of Tor bridges and other services where mere presence on the network is in itself a vulnerability.
>> seriously would consider that "safer" or "less error prone", starting > > Yes the risk of adding exploitable holes to the kernel is signficantly > lower. In the case of a Tor bridge, when people are able to scan the entire internet, as they are, they find Tor bridges and then add those bridges to a database or to various national firewalls. Increasing scanning resistance improves the security of such bridges - though a passive (eg: sniffing) adversary may still discover such a bridge for blocking, this kernel modification has a second benefit - it will prevent most exploitable conditions from having an avenue of attack. Such an attacker, even if they know the IP of a bridge will need to find a way to break TLS or any of our other transport layer security protocol that we're using. I think that generally, I would prefer if the code didn't use MD5 but otherwise, I don't see any real disk of adding an exploitable hole. It seems silly to disable it by default though - ideally, I'd like a sysctl to ensure that Tor could use this without making the user recompile their kernel. That is more of a pain than running a userspace helper, I think. All the best, Jacob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
