Steven D'Aprano <st...@pearwood.info> posted 200902171110.00439.st...@pearwood.info, 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
