[Pan-users] Re: Save attachment file permissions

[Duncan]

Steven D'Aprano <address@hidden> posted
address@hidden, excerpted below, on  Tue, 17 Feb
2009 11:10:00 +1100:

> On Tue, 17 Feb 2009 07:30:55 am Paul Crawford wrote:
>> I just tried saving a suspect file of the avi.exe sort to see how it
>> behaved under LINUX using Pan 0.132 and I found it used '755'
>> permission settings thus rendering it (theoretically, at least)
>> executable.
> 
> Oh boy. I've just confirmed this in the wild:

> This contains a trojan "Private-Amelie-14-27.avi.exe" which is saved as
> executable under Linux using Pan 0.132. In contrast, other attachments
> (e.g. JPEGs) are saved as non-executable.

> Under Linux, files are created with default permission 644, which is
> non-executable. This *strongly* suggests that Pan is deliberately
> setting the executable bit on exe files (and others?).

OK, the following out of context could certainly seem defensive and 
accusatory.  However, considering the on first appearance wild claims 
being made, and the lack of anything other than circumstantial evidence 
given supporting said apparently wild claims, I believe it's an 
appropriate response.  No offense (personal or otherwise) intended, 
however, so all you readers out there, don't take it wrong.

With that in mind...

The above claim, that under Linux, files are created with default 
permission 644, is simply not accurate.  It's too general (perhaps 
certain distributions, not "Linux") and lacks a description of the vital 
role umask plays in determining default file permissions.

More accurate (tho not necessarily absolutely correct, there's very 
possibly more to the story in at least some cases) is to say that files 
are normally moved/copied with their current permissions modified by the 
user's umask setting, which masks bits that should NOT be set by default 
(that IOW must be specifically turned on), or created (as opposed to 
saved) with 0666 permissions modified by the umask.  Normally, the 
distribution sets the umask to something sane like 0027 (masking write 
for group and rwx for world, which would produce 0640 permissions) for 
normal users and 0002 (masking write for world, produces 0664 
permissions) for root, tho the user umask can be 0077 (masking everything 
for group and world, producing 0600 permissions) for more security or 
0022 (masking only write for group and world, producing the 0644 you 
claimed was the default) for less.

Thus what you were suggesting as the Linux default is the default effect 
of a particular distribution after its default umask settings have been 
applied.  See more by issuing "help umask" and/or "man umask" at the 
shell prompt, or google the term.  Meanwhile, you can of course set your 
own user umask as desired, but be careful changing the umask for root as 
some package managers, etc might not handle it well and you'll end up 
with incorrect permissions applied to installed files.

All that said, you are correct in the limited context of the executable 
bit, as the default permissions on a created file given a umask of 0000 
(thus nothing masked) are 666, not 777, the executable "octal 1" bit 
being unset by default.

> Now, it's true that Windows executables are *mostly* harmless on Linux.
> I say "mostly" because:
> 
> * There are rare viruses which will execute under both Linux and
> Windows. E.g. the Simile/Etap virus, which infects both Portable
> Executable (Windows) and 32bit ELF files (Linux) applications.
> 
> * Some people do run Wine, and have exe files configured to run in Wine
> on a double-click. Wine is good enough at emulating Windows that it can
> run viruses and trojans.

Indeed.  And folks have gotten in trouble with that setting as well, 
which is why any distribution setting it by default is effectively 
begging for a kick in the security family jewels, so to speak, just as MS 
has been begging for and has so many times gotten what it asked for in 
this regard, over the years.

>> OK, I know this is a Windows virus file, but it seems very bad practice
>> as no doubt someone could post a shell script of malicious program for
>> LINUX as well.
> 
> Absolutely.

Agreed.

>> Should it not default to '644' under *all* cases, and at least force
>> the user to use chmod if they REALLY do want to execute some downloaded
>> attachment?
> 
> Yes yes oh gods yes!

Agreed.

> If I'm right that Pan is specifically setting the executable permission
> based on the file name, and I can't imagine how it could not be, I have
> to ask: what on earth was Charles thinking?

If you are correct, indeed "What on earth was Charles thinking?".  
However, without actually checking the sources, I do believe pan is the 
culprit here.  I'd guess it's either the desktop environment or more 
likely the distribution, wanting to be "helpful", tho given the above 
demonstrated lack of knowledge of umask and its implications, I'd assign 
at least equal possibility that it's a PEBCAK issue.  (Look it up if you 
need to.)

> After using KDE for something like six or seven years, I was horrified
> to discover that double-clicking a script *executed* the script instead
> of opening it in an editor... and executed it in the root of my home
> directory instead of the directory it was in, thus maximising the damage
> it did when it ran. (At least Gnome *asks* whether you want to open or
> launch executable scripts.) In six years, I had never double-clicked an
> executable script, and the first time I did, I lost data.

Double-clicking the script in /what/?  Konqueror?  On the desktop?  In 
some other file manager? (Krusader or Dolphin perhaps? mc?)  If it's a 
KDE based file manager (Konqueror, Krusader, Dolphin), it's using the 
mimetypes (aka file associations) with the defaults set by KDE, as 
modified by the distribution, as modified by the admin, as modified by 
the user.  Now I believe execution is indeed the KDE default, but it's 
the default that would be expected by many.  Arguably it would be the 
responsibility of the security conscious distribution or failing that, a 
security conscious admin, to protect the user from himself if they are 
not judged to be generally responsible enough to handle the normal 
defaults.  Only the distribution knows whether it's targeting the 
experienced user or the newbie that needs security hand-holding, and only 
the installing admin knows (because he surely based his choice of 
distribution partly on this knowledge or he's not a very good admin) how 
well the distribution's target matches the needs of the particular 
installation, and even of particular users if they are different than the 
normal user the installation is setup for.

As for where it executed, /anything/ executes with $PWD (present working 
directory) set to the user's home dir if it has not been instructed to do 
otherwise.  I believe that's in the POSIX specification.  That's the way 
Unix including Linux /works/.  Changing that behavior would cause MANY 
MANY problems due to it being that way "forever".  Various system 
services would fail to work correctly... apps would fail to find their 
config, all sorts of problems.  Again, for individual cases, it's 
something the user or the admin can change where appropriate.

If the behavior isn't what is desired, it's up to the user, or the admin 
acting for the user via system policy, or the distribution choosing a 
suitable system policy default, to change it.

Oh, BTW, "I lost data".  If you were the admin, you had a backup, so 
didn't loose more data than you were willing to sacrifice as the best 
balance for you between constant backups and lost data, right?  If you 
weren't the admin, you asked the admin to restore from the backup they 
had based on their evaluation of that balance, right?

IOW, no big deal, because by default or by deliberate choice, you had 
already chosen the balance between hassle and data security due to 
backups.  You cannnot NOT make that choice any more than you can NOT make 
the choice about the trustworthiness of an executable you choose to risk 
running.  By NOT making it, you are effectively saying that ANY amount of 
backup hassle is too much to be worth saving ANY OR ALL your data, so by 
definition, you are willing to lose 100% of your data and it's no big 
deal.

> I can't even say I'll never do it again, because I write a lot of
> executable Python scripts, and I edit them from the GUI but execute them
> from the command-line. I'm sure it will happen again eventually, because
> I'm only human.

Well, someone with the tech know-how to write python scripts is assumed 
to also have the tech know-how to protect himself from their unwanted 
effects...  In particular, the GUI file delete has this thing called the 
recycle or trash bin, that you can retrieve deleted items from if 
necessary...

Meanwhile, you're certainly not the only one to have had what the kernel 
hackers call a "brown bag incident" (because it's embarrassing enough 
you'd ordinarily not want folks to know who it was, and would thus wear a 
brown bag over your head so as to be anonymous) due to a script.  Not 
long ago I was running my first git bisect while investigating a kernel 
bug I had reported.  As such, I was creating various shell script helpers 
that fit the way I work to ease and semi-automate the process...  Well, 
long story short, I typoed a variable name and did a rm -r $xya/* where 
the variable should have been $xyza... $xya was therefore empty...

Let's just say I realized something was wrong when I saw errors about 
deleting devices in /dev/*, and make the observation that /dev is ordered 
AFTER /bin (but luckily, BEFORE /usr)...

So I certainly know your pain.  However, I'm a big boy now and should 
have known enough to test it with a -i, or at LEAST not test it as ROOT.  
As I said, a brown bag incident, especially when I had to go explain on a 
kernel bug why the results of my git bisect bug-to-commit tracing was 
taking so long!  (FWIW, I just left it as a "brown bag incident", on the 
bug.)

Luckily (or more accurately, by knowledge and deliberate action based on 
it, not a lot of luck involved, really), however, this admin knows that 
an occasional fat-fingering is a given, and I had backups to a reasonable 
balance for me.  I lost some data, yes, but the loss was limited not only 
by my catching the problem mid-way, but by the choice I had already made 
about what I considered an acceptable amount of data loss given the 
tradeoff hassle of making the backup.  So basically, "Yes it's a hassle, 
but no big deal overall, as the insurance covered it."

> And honestly, any tech using a GUI is eventually going to be faced with
> a filename like
> (say)
> 
"Battlestar.Galactica.S02E19.A.Really.Long.Episode.Name.EZTV.DVDRIP.blah.blah.blah.blah.avi
> exe" and double-click it without noticing the .exe part. It's easy to
> do. There's a reason why Unix and Linux defaults to making files
> non-executable and requiring people to explicitly make them executable.

Actually, it's more accurate to say that a tech knows (or should know) 
that "things happen", be they fat fingering on his own part, equipment 
failure, or bugs in the software.  It may indeed be fat-fingering in the 
form of a double-click where it shouldn't have been, but it could be any 
of a dozen other things, too.

Specifically, I have NEVER, not in eight years on Linux, not in the same 
time on MS platforms, EVER, double-clicked (or hit enter) on an 
executable that I was not aware was an executable.  (Note what I did and 
did not claim.  I did NOT make the claim that I have never run one in 
error, or that I've never "brown-bagged" something.)  It's NOT easy to 
do, as long as one takes minimal precautions.

Matter of fact, in most Linux GUIs at least, the icons for executables 
are all generally recognizable as separate from those for data files.  
We've learned from MS here, and an apps' data files with no exceptions 
I'm aware of do not EVER have the same icon as the executable used to 
process them.

But even when that was NOT the case back when I still did Windows, I 
never clicked on an executable thinking or expecting it to act as a data 
file, in part because one of the first things I always did was turn off 
that absolutely stupid hide extensions option, and in part because I 
never clicked on a file that came from the Internet or other low-trust 
source, without knowing at least some minimal basics about it -- like 
whether it's an executable or not.

So I don't believe it's accurate to claim that "any tech" (particularly 
as opposed to making the claim about "any ordinary Joe", a claim which 
might arguably be correct, where it's not necessarily so when the 
operative word is "tech" and it's qualified with "any", without limiting 
qualification, such that a single counter-example disproves the entire 
claim) using a GUI MUST at some point click a deceptively named 
executable without knowing it is one.  However, as I already agreed, the 
more general statement, that any tech should be acutely aware of the 
possibility of fat-fingering something, what it is doesn't matter, and 
indeed, of the superset possibility that /something/ will go wrong, and 
thus prepare for it accordingly, with backups, by minimizing the fat-
fingering possibilities where it makes sense to do so, etc.

> What Pan does, by accident or design, is a shockingly bad thing. It's
> introducing typical Windows-like insecurity into Linux.
> 
> (Pan is hardly the only culprit. KDE and Gnome have introduced launchers
> that don't need to be executable to execute. Foolish foolish foolish.)

Actually, as I said, I believe it's far from demonstrated that it's pan's 
doing in this case.  I think it far more likely that it's either the 
user's doing (or lack of doing, thru ignorance of things like umask, and 
the admin, distribution, and possibly upstream desktop environment, in 
their turn for not having sane defaults), or something to do with the 
desktop environment itself or some other interacting system policy agent 
(in the generic sense), not pan.

Why do I believe this?  Simple, really.  Those who have been around pan 
and these groups/lists awhile know Charles does NOT like bloat, and pan-
specific code to arbitrarily manage file permissions would be just that, 
when there are already perfectly adequate mechanisms such as umask 
available to handle it, and they do a better job way more consistent with 
generally configured system and user policies than pan could ever do 
trying to enforce things on its own.  It's not logical to have such code 
in pan to begin with, so I'd be very surprised if it did, and no offense 
intended, but it's going to take more proof than the wild claim of 
someone who apparently doesn't even know about umask to convince me 
otherwise given that default permissions are the precise thing umask is 
supposed to help manage.

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