Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Mikhail,

What follows is an educated guess, but only a guess...

Mikhail Morfikov via Gnupg-users <gnupg-users@gnupg.org> wrote:
> gpg wants to connect to the network, but it looks like it wants
> also TCP/993 (IMAPS). This happens when I use Thunderbird as a
> mail clinet + Enigmail extension, which make some use of gpg.
...
> doesn't show anything that points to gpg. When I prevent gpg
> from connecting to this port, I can't access my mail account in
> Thunderbird -- it just tries to refresh the inbox, but it just
> stalls. When I restart Thunderbird at this point, then
> everything backs to normal, and I don't see any drops in OUTPUT
> traffic. Could anyone explain what's going on here?

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.

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).

If your firewall then sends RST packets to close connections
which gpg isn't supposed to be making, it will actually be
shutting down the connections Thunderbird was using and you won't
be able to access your mail.

(This scenario matches what you have described, but I haven't
reproduced your problem to verify it is indeed the case.)

Hope this helps!
- Bjarni

- --
PageKite.net lets your personal computer be part of the web

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2wUdYACgkQjgA3FgDP
lJH11ggAk3SujXyDYqzLdDkbDksZwkdZEE5fhMPfukMGrs6/N2L08yzUxKYTx9v4
QdTY5BmUVl2sG21eUY+y90Y0YK3lpHJNrfe9Rrw5QnHXjB4B1fuzQCuUfwVv3YGt
kHtj95clWgHsWWqIh5AWnt4LDk4inZ6+SVhj0k49eyea3GIelL/iJxxQ9wFjbPVY
sbxiUP83qtTgKDVW98rneVS8mgJ6/d0Qf+RQFRmR3E+6RYPDo0FoNhpKGodTN4BO
Ph+GuwuHBu0o7cjxdsgNdFY8v1GgcpQOtJ9gbZs5ysBeG4nrejxwK1EFbiAh+YX/
cZTfoE7/g0PJ877299r5C1uPAUTXHg==
=5yoS
-----END PGP SIGNATURE-----

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.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello!

Mikhail Morfikov <mmorfikov@gmail.com> wrote:
> 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
[...]
> 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.
[...]
> 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?

I think yes, it does. The assumption here is that gpg inherits
the file descriptor after the connection is opened - so the SYN
is already sent and recorded as having come from Thunderbird.

The other assumption is that the firewalling systems are confused
about which process owns the packets, because after the
fork()/exec() there are actually two possibilities. Without
keeping expensive historic state about which process *created*
the connection, it's impossible for the kernel to know which is
the owner and some connections will get misreported.

All pretty plausible, no?

> > 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()
[...]
> Should the `Enigmail's gpg launcher` take care of that? Maybe
> is a bug or something?

IMO, yes, if this is what is going on it is almost certainly a
bug. Whatever code is calling exec() should be closing file
descriptors first. Not doing so can lead to all sorts of wasted
resources and even deadlocks if processes depend on file
descriptors getting properly closed in a timely fashion.

> > 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.

Since (I think) Enigmail's gpg processes are usually short-lived,
you're unlikely to see this happen, and if it does it's likely to
be harmless. If the gpg processes were long-lived, it could over
time lead to resource exhaustion (running out of file descriptors
or RAM).

The symptoms that didn't match this, was that Thunderbird was
unable to download mail. If this was *only* happening with
connections that Thunderbird thought it had closed, then your
firewall rules wouldn't have impacted TB's operations.

Again, I'll stress that this is all educated guesswork. But the
symptoms match. I've created bugs like this myself in the past.
Of course, maybe GnuPG does like to connect to port 993. I
haven't ruled that out, but if that were the case, you'd probably
have seen SYN packets in your logs. :-D

- Bjarni

- --
PageKite.net lets your personal computer be part of the web

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2wq2QACgkQjgA3FgDP
lJE3KAgAtVKIkBlAXRXhtvsuWvPUFoygc/LF7ice2PWKbBada8yIiY3U0F8YtbSJ
bmtm+bqPhPijBuAH8O0RdGkFQsvyUFSYzvXKE92Tb6jZF5NEdOktVkIRbwurNOAS
0MreNosHaV9wPx5mm1DtY5UkDF9ccZzdQXdXRGvoMz5uKBdRgxtHaaBWS1+0pwey
VsAqmjeSB8UOdJDpnqIXRxxyoZ7Ti/Aru4KweKoYVnIac39fFg2GRY3mRD0D0pIL
nI+Znnm0nAi64wLQ6/hVEJ2175TN6g/XgRtCCPyjytmrFrIMnOwB6t+ZmSWADUH9
QzQpKFwoW1mC/+/7aDT0unQlUtDGDg==
=j1yU
-----END PGP SIGNATURE-----

Bjarni Runar Einarsson wrote on 23.10.2019 21:35:
[...]
>>> 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()
> [...]
>> Should the `Enigmail's gpg launcher` take care of that? Maybe
>> is a bug or something?
>
> IMO, yes, if this is what is going on it is almost certainly a
> bug. Whatever code is calling exec() should be closing file
> descriptors first. Not doing so can lead to all sorts of wasted
> resources and even deadlocks if processes depend on file
> descriptors getting properly closed in a timely fashion.

Your guess is perfectly right, that's exactly what happens. Enigmail
uses a standard library provided by Mozilla for add-ons to execute
processes. Earlier versions of the library did close all file
descriptors correctly. But the library is written in JavaScript, and
closing all file descriptors could sometimes lead to Thunderbird/Firefox
crashes. Therefore that part has been disabled.

It's therefore not surprising to see such open connections from gpg
processes, but I don't consider this bad.

-Patrick

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 24/10/2019 08:21, Patrick Brunschwig wrote:
> Your guess is perfectly right, that's exactly what happens. Enigmail
> uses a standard library provided by Mozilla for add-ons to execute
> processes. Earlier versions of the library did close all file
> descriptors correctly. But the library is written in JavaScript, and
> closing all file descriptors could sometimes lead to Thunderbird/Firefox
> crashes. Therefore that part has been disabled.
>
> It's therefore not surprising to see such open connections from gpg
> processes, but I don't consider this bad.

Thanks for the info -- at least I know what's going on. Now I'm just
wonder how I'm supposed to write my FW policy when apps can behave like
this one... Fortunately it's just TB so far (from ~150 apps), so making
one exception isn't that big of a deal.

On Thu, 24 Oct 2019, Patrick Brunschwig <patrick@enigmail.net> wrote:

> Bjarni Runar Einarsson wrote on 23.10.2019 21:35:
> [...]
>>>> 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()
>> [...]
>>> Should the `Enigmail's gpg launcher` take care of that? Maybe
>>> is a bug or something?
>>
>> IMO, yes, if this is what is going on it is almost certainly a
>> bug. Whatever code is calling exec() should be closing file
>> descriptors first. Not doing so can lead to all sorts of wasted
>> resources and even deadlocks if processes depend on file
>> descriptors getting properly closed in a timely fashion.
>
> Your guess is perfectly right, that's exactly what happens. Enigmail
> uses a standard library provided by Mozilla for add-ons to execute
> processes. Earlier versions of the library did close all file
> descriptors correctly. But the library is written in JavaScript, and
> closing all file descriptors could sometimes lead to Thunderbird/Firefox
> crashes. Therefore that part has been disabled.
>
> It's therefore not surprising to see such open connections from gpg
> processes, but I don't consider this bad.
>
> -Patrick

Is the following correct:

When I use gpg to just encrypt or decrypt a file already on my
computer/OS's file system, then gpg does not open any formal
channels of communication going outside my computer/OS.

oo--JS.


>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Fri, 25 Oct 2019 12:23, Jay Sulzberger said:

> Is the following correct:
>
> When I use gpg to just encrypt or decrypt a file already on my
> computer/OS's file system, then gpg does not open any formal
> channels of communication going outside my computer/OS.

No. By default gpg may go out for key discovery, CRLs, version checks
etc. If you do not want this you can use the gpg option
--disable-dirmngr or, to be 100%, do not install dirmngr.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On Mon, 28 Oct 2019, Werner Koch <wk@gnupg.org> wrote:

> On Fri, 25 Oct 2019 12:23, Jay Sulzberger said:
>
>> Is the following correct:
>>
>> When I use gpg to just encrypt or decrypt a file already on my
>> computer/OS's file system, then gpg does not open any formal
>> channels of communication going outside my computer/OS.
>
> No. By default gpg may go out for key discovery, CRLs, version checks
> etc. If you do not want this you can use the gpg option
> --disable-dirmngr or, to be 100%, do not install dirmngr.
>
>
> Salam-Shalom,
>
> Werner

Dear Werner, thank you for answer! And for work on GNUpg!

oo--JS.

>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
>

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users