Let's assume you are right, and it's because of the way the linux works. When I clear the conntrack table, the following messages appear in the FW log (I don't block the gpg packets for now, just log and accept them in its rule):
Oct 23 17:59:14 morfikownia kernel: * gpg * IN= OUT=bond0 \ SRC=192.168.1.150 DST=64.233.165.108 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=63468 DF PROTO=TCP \ SPT=41414 DPT=993 SEQ=50635057 ACK=2111326021 WINDOW=501 RES=0x00 ACK PSH URGP=0 \ OPT (0101080A1268C9EA725E3175) UID=1000 GID=1000 Oct 23 17:59:14 morfikownia kernel: * gpg * IN= OUT=bond0 \ SRC=192.168.1.150 DST=64.233.165.108 LEN=86 TOS=0x00 PREC=0x00 TTL=64 ID=29858 DF PROTO=TCP \ SPT=41416 DPT=993 SEQ=4217185545 ACK=3828226663 WINDOW=501 RES=0x00 ACK PSH URGP=0 \ OPT (0101080A1268CA10E67D9F27) UID=1000 GID=1000 Oct 23 17:59:14 morfikownia kernel: * gpg * IN= OUT=bond0 \ SRC=192.168.1.150 DST=64.233.165.108 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=35167 DF PROTO=TCP \ SPT=41510 DPT=993 SEQ=2292653331 ACK=2720180704 WINDOW=501 RES=0x00 ACK PSH URGP=0 \ OPT (0101080A1268CAFEB48EC039) UID=1000 GID=1000 So it's an ACK packet (possibly one per already opened connection, since src ports differ), and not SYN. So it's not a new connection for sure. Also, someone once gave me the following audit rule: -a exit,always -F arch=b64 -S connect -k MYCONNECT to find what actually is trying to connect to the net. Each time I see some blocked OUTPUT packets in the FW logs, I usually run `audit` to find out what that might be. In all cases so far, in the audit log I was able to match the dst IP or dst port that I saw in the FW logs. But in the case of gpg, there's no entry that would match anything that was printed above. So will this match to your idea? > The way processes are spawned on Unix, fork()/exec() will by > default inherit open file descriptors. Thunderbird/Enigmail will > fork()/exec() to launch gpg. > > Each active TCP/IP connection has an open file descriptor. So, if > Enigmail's gpg launcher hasn't taken care to close unneeded file > descriptors after fork() and before exec(), gpg will inherit the > connections Thunderbird had open at the time of invocation. Should the `Enigmail's gpg launcher` take care of that? Maybe is a bug or something? > Since gpg doesn't actually know anything about these connections, > it likely won't close them, they'll stay open (potentially even > after Thunderbird has closed them, although that doesn't match > all the symptoms you've described). So what doesn't match the symptoms I've described? Maybe I have to pay attention to certain things, and than it will match.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
