[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!) 

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]