[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pan-devel] @ b2069b3c8b680, working well (Re: ANN: SSL Support)
From: |
Duncan |
Subject: |
[Pan-devel] @ b2069b3c8b680, working well (Re: ANN: SSL Support) |
Date: |
Wed, 16 Nov 2011 06:11:11 +0000 (UTC) |
User-agent: |
Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT b2069b3 /st/portage/src/egit-src/pan2) |
Heinrich Müller posted on Thu, 10 Nov 2011 08:43:44 +0000 as excerpted:
> Btw, there's a gui option for the certificates now. Edit->Edit SSL
> Certificates
I just updated for the first time since Nov 1. At b2069b3c8b680,
everything seems to work fine with gmane at least, in ssl mode.
It was nice getting the cert prompt, and later, checking the gui option
you mention above.
I did have an initial cert-setup hiccup, however, with pan segfaulting
when I tried to accept the cert, but that was arguably my fault. The
rest is a discussion of that and a resulting request.
Background: Back some years ago, there was some discussion over an
arguable security issue with pan at the time. If someone posted an
attachment with the executable bit set (at least some encoding forms
record and transfer standard Unix permission bits), pan was saving the
attachment with the executable bit set as well. If a user then browsed
the save dir and clicked on that attachment, some file managers would see
the executable bit set and try to execute the file, no questions asked.
Obviously that's the same sort of malware vector that has gotten MS and
MS users into so much trouble over the years. The eventual result was a
patch, now in pan mainline for some time, that stripped the executable
bit. However, IIRC, that patch got dropped somewhere along the line,
leaving users unprotected once again, before being added again.
(Still background:) Meanwhile, I pointed out that umask was designed to
prevent just this sort of issue, and confirmed with my own testing that a
umask of 0137 did indeed have the desired effect. I added a umask 0137
line to the pan-wrapper scripts I already used (mainly in ordered to have
several separate pan data and config dirs, as I've explained many times,
but once I had the wrapper scripts, adding things such as this was easy!
), and posted the umask workaround to the pan list. I suppose a number
of people ended up with wrapper scripts and an exe-bit-stripping umask
back then, but over the years, they've probably bitrotted and I doubt
many are using wrapper scripts, especially with exe-bit-stripping umasks
in them, today. However, I DID feel a bit vindicated when someone
pointed out that the patch had been dropped somewhere along the line,
leaving users unprotected again, since I still had that umask set, thus
confirming the wisdom of that old security saying, "defense in depth!"
As a result, I was always protected.
Now the problem: As I'm sure you know, the executable bit has a rather
different meaning on directories than it does on files. As long as pan
is using the same old directories it has used for years, with the
executable/enter bit set, so it can access what's inside, no problems.
BUT, twice recently I've been bit by this umask problem, first when pan
created the encoding-cache dir and the umask killed the executable/enter
bit on it, and now, when pan created the ssl_certs dir.
In the first case, I just got a mystifying error when pan couldn't do the
encoding it expected. With ssl_certs, however, it REALLY expects to be
able to access the dir in ordered to save the new certificate, and
segfaults when it can't!
OK, so this is partly my problem due to the umask that I have pan
inheriting when it starts. There's an old saying, if it hurts when you
bang your head against the wall, quit banging!
But I /like/ my "defense in depth", and anyway, after a bit of confusion
with the encoding-cache thing as I had long ago forgotten about the umask
thing, I'm aware of the issue now, and immediately suspected the umask
issue when pan started segfaulting trying to install a certificate.
** So, my idea is this: Create a new create-dir function wrapper, that
checks the permissions mode after creating the dir, and either spits out
a nicely worded error explaining the problem if it's not executable, or
simply corrects it, setting u+x (don't touch group and other perms, tho,
as that's not normally necessary and the user may have a reason for
masking them). Then simply replace all calls to create-dir (or more
likely, open with create if it doesn't exist) with calls to this function
that checks for sane permissions after dir creation, and either warns or
changes them (your call, I'd prefer a warning and let the user handle it,
but I recognize that my viewpoint tends to favor security over usability
at times, still, a nice warning beats a segfault for usability any time!)
accordingly.
For all I know, there's already a gtk or whatever library function that
does this, since it would seem to be a reasonable candidate for a library
given the number of apps that could use it, but I'm not a coder, so won't
know for sure. But even creating the wrapper function should be
reasonably easy compared to some of the stuff you've been working on, and
I'd guess the replacement could be pretty much global search and replace,
once you have the wrapper function created and tested.
Of course, the simpler solution would be to simply check for a failure
status on the call to save the certificate, and deal with that. That'd
still be a good idea, but it seems to me that fixing the umask
permissions issue for all pan directory open-with-create calls at once,
should be easy enough, using the wrapper-function approach, and that'd
cure a lot of yes, I'll admit, corner cases, but it'd cure a lot of them,
all at once.
Sound like fun? =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
- Re: [Pan-devel] at GIT 7e49a9b still the same here, plus some research I've done (seems AW works, but not GN nor Gmane (Re: ANN: SSL Support)), (continued)
- Re: [Pan-devel] at GIT 7e49a9b still the same here, plus some research I've done (seems AW works, but not GN nor Gmane (Re: ANN: SSL Support)), Duncan, 2011/11/22
- Re: [Pan-devel] at GIT 6ffb80b still the same here: seems AW works, but not GN nor Gmane (Re: ANN: SSL Support)), walt, 2011/11/19
- Re: [Pan-devel] at GIT 6ffb80b still the same here: seems AW works, but not GN nor Gmane (Re: ANN: SSL Support)), Duncan, 2011/11/20
- Re: [Pan-devel] at GIT 6ffb80b still the same here: seems AW works, but not GN nor Gmane (Re: ANN: SSL Support)), walt, 2011/11/20
- Re: [Pan-devel] at GIT 6ffb80b still the same here: seems AW works, but not GN nor Gmane (Re: ANN: SSL Support)), Duncan, 2011/11/20
- Re: [Pan-devel] at GIT 6ffb80b still the same here: seems AW works, but not GN nor Gmane (Re: ANN: SSL Support)), Heinrich Müller, 2011/11/21
- Re: [Pan-devel] at GIT 6ffb80b still the same here: seems AW works, but not GN nor Gmane (Re: ANN: SSL Support)), Heinrich Müller, 2011/11/23
- [Pan-devel] having compile problems with your GIT 566616f master (Re: ANN: SSL Support), SciFi, 2011/11/27
- Re: [Pan-devel] having compile problems with your GIT 566616f master (Re: ANN: SSL Support), Heinrich Müller, 2011/11/27
- Re: [Pan-devel] at bb11b8e now: no crash, but still no cigar (Re: ANN: SSL Support), Heinrich Müller, 2011/11/10
- [Pan-devel] @ b2069b3c8b680, working well (Re: ANN: SSL Support),
Duncan <=
- Re: [Pan-devel] @ b2069b3c8b680, working well (Re: ANN: SSL Support), Heinrich Mueller, 2011/11/16
- Re: [Pan-devel] @ b2069b3c8b680, working well (Re: ANN: SSL Support), Heinrich Müller, 2011/11/16
- Re: [Pan-devel] @ b2069b3c8b680, working well (Re: ANN: SSL Support), Duncan, 2011/11/16
- Re: [Pan-devel] @ b2069b3c8b680, working well (Re: ANN: SSL Support), Heinrich Müller, 2011/11/16
- Re: [Pan-devel] ANN: SSL Support, Heinrich Müller, 2011/11/09