Follow up: How to write a Linux virus
Yesterday I published an article about How to write a Linux virus in 5 easy steps. There has been quite an overwhelming response for this. Within just a few hours this article became my most visited blog post ever. Wow! Just goes to show that either the article hit a real nerve, or the other articles on my blog are just really boring. :-)"
Posted Feb 13, 2009 0:07 UTC (Fri)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Feb 26, 2009 12:15 UTC (Thu)
by gvy (guest, #11981)
[Link] (1 responses)
So far they seem to fail to understand that XML is not really human readable, that security *is* something to consider, and that they're prolly not the brightest folks on the planet to skip learning from previous experience and mistakes.
Okay, I'm a humble maintainer for some ~200 packages with quite few patches submitted anywhere and even fewer things designed and implemented. I'd probably just shut up and drink that pepsi until getting fed up and dropping all of this crazy superfluous "hi-tech" altogether.
Posted Feb 26, 2009 19:56 UTC (Thu)
by nix (subscriber, #2304)
[Link]
(Sanity, I suspect. I'm still not sure exactly what the hell an .fdi is
Posted Feb 13, 2009 0:36 UTC (Fri)
by massysett (guest, #52736)
[Link] (1 responses)
Posted Feb 13, 2009 10:29 UTC (Fri)
by epa (subscriber, #39769)
[Link]
Posted Feb 13, 2009 0:55 UTC (Fri)
by walters (subscriber, #7396)
[Link]
Posted Feb 13, 2009 2:05 UTC (Fri)
by Arker (guest, #14205)
[Link] (29 responses)
It's a KDE/Gnome problem. This is a result of mindlessly aping MS. This is inevitable, and will only get worse unless they radically rethink things, which sadly I dont see happening.
One more good reason not to sully *nix with 'desktop environment' thinking. My prediction is that unfortunately people will continue blithely along this path and the free DEs will be no more secure than Windows in a few more years. That's pretty much inevitable. However it still seems just vaguely imaginable that there are enough clued users in the 'linux' ecosystem to reject DEs and keep enough programs free of their crap that X remains usable without them. Unfortunately that seems quite unlikely as well, really, I'm just saying *possible*. :(
Posted Feb 13, 2009 3:50 UTC (Fri)
by JoshK (guest, #56628)
[Link]
Posted Feb 13, 2009 5:46 UTC (Fri)
by dkite (guest, #4577)
[Link] (27 responses)
If the executable file could contain the metadata, then there would be no
So we are stuck with a flawed system. What the .desktop file will run when
It must be noted that the execution is still within the permissions system.
Derek
Posted Feb 13, 2009 8:02 UTC (Fri)
by tzafrir (subscriber, #11501)
[Link]
/usr/share/applications/chatzilla.desktop:Exec=iceape -chat
A non-trivial command for an executable:
Posted Feb 13, 2009 8:37 UTC (Fri)
by roblucid (guest, #48964)
[Link] (3 responses)
If that was all they were intended to provide, the descriptive file could use a map db file for paths to icons and titles. Then .desktop files just need, position info and the look up key. No need to bloat every executable.
Posted Feb 13, 2009 11:20 UTC (Fri)
by dgm (subscriber, #49227)
[Link] (2 responses)
Posted Feb 13, 2009 12:38 UTC (Fri)
by roblucid (guest, #48964)
[Link] (1 responses)
How is that worse than interpreters for handling mime types?
Posted Feb 13, 2009 15:34 UTC (Fri)
by dkite (guest, #4577)
[Link]
Derek
Posted Feb 13, 2009 11:42 UTC (Fri)
by etienne_lorrain@yahoo.fr (guest, #38022)
[Link] (21 responses)
If you are talking of ELF executable file, then there is absolutely no problem: create some ELF section with standard names like:
Note that I still do not understand the general problem, if the .desktop file is executed under the "internet" user in the "internet" group, the virus can only modify "internet" files.
Posted Feb 13, 2009 12:30 UTC (Fri)
by tzafrir (subscriber, #11501)
[Link] (12 responses)
Posted Feb 13, 2009 13:31 UTC (Fri)
by efexis (guest, #26355)
[Link] (4 responses)
Windows just overlays the small arrow icon in the bottom left hand corner to signify that the icon is merely a shortcut to the application rather than the application itself when you're browsing the files. But hey, that's a pretty recent idea...
Posted Feb 13, 2009 14:59 UTC (Fri)
by hppnq (guest, #14462)
[Link]
One of the other posters of course hit the nail right on the head: until we have a mechanism that with reasonable security allows a user to validate the purpose of downloaded content, all other suggestions are pointless.
Posted Feb 13, 2009 19:00 UTC (Fri)
by vonbrand (guest, #4458)
[Link] (2 responses)
Unix (and thus Linux) is a multiuser system. I.e., each of the multiple users might have very well like different graphical interfases (each with its own icon set), or just use their own icons. That Windows (which is still very much a one user operating system, with just one graphical interface) does it differently is completely irrelevant.
Posted Feb 14, 2009 11:08 UTC (Sat)
by etienne_lorrain@yahoo.fr (guest, #38022)
[Link]
Posted Feb 16, 2009 9:18 UTC (Mon)
by dgm (subscriber, #49227)
[Link]
Posted Feb 13, 2009 16:00 UTC (Fri)
by dkite (guest, #4577)
[Link] (1 responses)
Java?
Interesting the immediate objection to this. Mustn't bloat the executable.
As for anything anyone gets by email or by downloading, that is another
The problem as it exists is that you are clicking on something that is not
http://archive.netbsd.se/?ml=xorg-xdg&a=2006-03&t...
Kinda illustrates why the desire to establish standards is, umm,
Derek
Posted Feb 13, 2009 19:26 UTC (Fri)
by tzafrir (subscriber, #11501)
[Link]
You just removed the icon from all of the Mozilla programs.
Furthermore, replacing a program with a wrapper script is a rather common practice.
Posted Feb 13, 2009 16:08 UTC (Fri)
by forthy (guest, #1525)
[Link]
What about hard-linking several commands to the same ELF file
(distinguish different functions by argv[0]), and have the ELF header in
the form icon-<name>, where the original file name is used to find
the
correct icon? Other formats: #! scripts could have a formal comment section after
the #! which defines icons. win32 files already have embedded icons. Java
files are really zip files, you can have an icon subdirectory. Anything
more? The main point however IMHO is that .desktop files can execute
arbitrary code, they should not be allowed to do so without +x flag. Thus
a user with a noexec /home partition can only symlink to
system-provided .desktop files (menu shortcuts and that like), which is
probably a reasonable restriction. Just downloaded .desktop files don't
execute upon clicking (maybe clicking on them should show up a .desktop
editor, telling unexperienced users that this .desktop file has marked as
non-executable and might be malicious). It has about the same effect as
embedding icons into the executable itself.
Posted Feb 13, 2009 17:17 UTC (Fri)
by iabervon (subscriber, #722)
[Link] (3 responses)
Java jars are zip archives with a directory for "what do you actually run". That's especially easy. a.out is hardly supported any more, and win32 goes with its own system (win32 executables depend on having a registry of some sort).
Scripts are kind of annoying, but there's probably an easy enough way to put something in them near the beginning using their native comment syntax plus a special tag.
Posted Feb 13, 2009 19:31 UTC (Fri)
by tzafrir (subscriber, #11501)
[Link] (2 responses)
Posted Feb 13, 2009 20:46 UTC (Fri)
by iabervon (subscriber, #722)
[Link] (1 responses)
In the dynamic linker, check for a .desktop.(basename of $0) section, and rewrite argv to have the given options, if any, between $0 and $1. In the launcher, offer a filename argument if the section has a "filearg" symbol. The launcher could also pull out other information, like icons, names, suitable MIME types, etc. And the launcher actually executes "/usr/share/applications/iceape foo", so if it's looking at isn't executable, it'll get an error.
As a bonus, you can actually execute these from the command line with the same effect that they have in the launcher.
Posted Feb 14, 2009 8:34 UTC (Sat)
by ringerc (subscriber, #3071)
[Link]
You might be able to avoid that by borrowing a spare (if there is one) ELF header flag to indicate "this is a desktop application".
In all honstly, though if you're going to mangle things that much why not take NextSTEP / Apple's approach of .app dirs with self-contained metadata?
Anyway, none of these proposed solutions address things like users wanting to make their own app links, make custom launchers with different arguments to apps, add launchers for apps they've compiled themselves, etc. Making .desktop files require execute permissions would be a big step.
Posted Feb 13, 2009 16:11 UTC (Fri)
by droundy (subscriber, #4559)
[Link] (5 responses)
The trouble is that the user of a process running an executable is not determined by the owner of the executable, but rather by the user who started the process. Changing this would have serious implications. What you're proposing really is more like what smack does than something you'd want to hack up using traditional users and DAC.
Posted Feb 13, 2009 17:08 UTC (Fri)
by etienne_lorrain@yahoo.fr (guest, #38022)
[Link] (1 responses)
Unless sticky bit is set, I thought it was obvious to set it.
Posted Feb 13, 2009 21:32 UTC (Fri)
by quotemstr (subscriber, #45331)
[Link]
Posted Feb 13, 2009 19:35 UTC (Fri)
by tzafrir (subscriber, #11501)
[Link] (2 responses)
Posted Feb 14, 2009 11:34 UTC (Sat)
by etienne_lorrain@yahoo.fr (guest, #38022)
[Link] (1 responses)
Note that I do not know about downloaded data files, maybe it would be safer to to the same system (owner "internet") and open the viewer under the "internet" account in case the data tries to exploit a security bug of the viewer - but that is not the initial problem we were talking about.
Posted Feb 19, 2009 14:53 UTC (Thu)
by mrshiny (subscriber, #4266)
[Link]
Posted Feb 16, 2009 16:55 UTC (Mon)
by salimma (subscriber, #34460)
[Link]
Not sure what the equivalent of desktop files is in OpenStep/OSX-land. Probably non-existent.. in that case, downloaded desktop files should be considered as suspect as executables.
Posted Feb 20, 2009 11:02 UTC (Fri)
by bockman (guest, #3650)
[Link]
Oh, and of course it is always a good idea to remove the executable bit from anything downloaded
Posted Feb 13, 2009 8:33 UTC (Fri)
by foo-bar (guest, #22971)
[Link] (25 responses)
Pls don't tell that it's because they are not real executables shell or perl scripts aren't executables either, however if you want to run them without manually specifying an interpreter (which from the user's prospective is similar to double-clicking) they have to have execute permissions.
Posted Feb 13, 2009 8:53 UTC (Fri)
by roblucid (guest, #48964)
[Link] (4 responses)
Posted Feb 13, 2009 9:46 UTC (Fri)
by Tuxie (guest, #47191)
[Link] (1 responses)
.desktop files should really be treated as scripts because that's exactly what they are. There is no reason at all why someone would ever need to download a .desktop file and doubleclick it.
If such a need comes up though, just wrap it in a .tar.gz and let the user unpack it first, or require the user to right click the file -> properties -> make executable.
Posted Feb 13, 2009 12:55 UTC (Fri)
by roblucid (guest, #48964)
[Link]
Do I need this feature at all? Sounds like something I would prefer totally disabled. If the DE is allowing scripts to masquerade as content, then it's a bug, and if the DE relies on arbitary code execution scripts to function it appears to me to be poor design.
The problem is, how do you avoid content file formats being extended, with facilities like scripting?
Relying on user's not being gullible to avoid giving execute permission, is of limited value. The real problem goes deeper, hence the discussion of sand-boxing.
The data is tainted, the way to untaint it is via validation by trusted code.
Posted Feb 13, 2009 10:16 UTC (Fri)
by forthy (guest, #1525)
[Link] (1 responses)
There's also ppl installing software packages via a double-click on
Desktop. Of course. But then they know that they are going to install software
by doing so, and they should be prompted by the distribution's system
tool to install software. You can one-click install on OpenSuSE, and I
think it's save enough. It will pop up an "install software" program,
which displays what kind of software it wants to install, and even insist
on importing a GPG key. I'm not that happy with this GPG key import
stuff - they should have installed a signing chain so that you can trust
GPG keys that have been signed by some OpenSuSE master keys, because
otherwise, you can only blindly import it.
Posted Feb 13, 2009 13:03 UTC (Fri)
by roblucid (guest, #48964)
[Link]
So now, we have double-click installing programs into the system, and it's OK, because the stuff is signed, and warnings like entering a password to be root, and a general bside covering warning about trusting repositories is given.
OTOH, we have DE which seem willing to run arbitary code, without any precuations.
Posted Feb 13, 2009 9:38 UTC (Fri)
by DeletedUser32991 ((unknown), #32991)
[Link] (7 responses)
Posted Feb 13, 2009 10:02 UTC (Fri)
by dlang (guest, #313)
[Link]
# indicates comments in bash, perl, and many other scripting languages. they all cope quite nicely with #! in the first line (by having the interpreter executing the file ignore it)
at that point the desktop files could be executables in any language. they no longer need to be their own special thing.
on *nix you can have an executable called foo and with the #! 'magic' all you need to do is to execute it and the correct helper app is called with no ambiguity. you don't have to name things foo.pl, foo.php, foo.py, etc. (in fact naming things with extentions is likely to cause grief in the long run when you want to re-write a script in a different language, but find that everything else that calls that script includes a file extention in the name that they call)
Posted Feb 13, 2009 12:36 UTC (Fri)
by bluss (subscriber, #47454)
[Link] (2 responses)
If # are comments in the spec, that means we can introduce a format upgrade where a shebang line (#!/usr/bin/desktop-launcher) is required, and older implementations will treat it as a comment. Then slowly distributions can enforce the executable + shebang requirement.
It is actually very easy: Introduce the new format, and require it. Then handle backward-compatibility by throwing a warning when double-clicking old-style desktop files, with the option to mark it executable and add the shebang ("Do you truth this launcher? Items downloaded from iternet... It will run '/bin/binary'..", "[ ] don't ask me again", "Cancel", "Launch")
Posted Feb 13, 2009 13:01 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (1 responses)
Posted Feb 13, 2009 14:26 UTC (Fri)
by DeletedUser32991 ((unknown), #32991)
[Link]
Posted Feb 18, 2009 0:01 UTC (Wed)
by dwheeler (guest, #1216)
[Link] (2 responses)
I agree, this is a trivially-solved problem. In fact, there's a standard solution, it's just that GNOME and KDE don't use the standard in this case. Shame, shame - that needs fixing.
If a file is an arbitrarily-executable program (as desktop files are), then the system should require that the execute ("x") bit be set before it can be run. Period. It should have a "#!..." prefix at its beginning - so the spec should add that. (If you use #!/usr/bin/env ...., then you can even have PATH redirect, but I digress).
Unfortunately, there will probably need to be some temporary stopgaps while everyone transitions to what they SHOULD have been doing in the first place.
As a stopgap measure, the GUI environments could process files specially if they are executable and end in ".desktop".
Also, the GUIs might accept any desktop file stored in "/usr/share/applications/", even if its "x" bit isn't set; it requires root privilege to write there anyway, so whoever put the .desktop file there was trusted.
That way, the transition is pretty painless; once people have switched
over, the stopgaps can be removed.
If you always run a given program to process a given file, then it shouldn't need an execute bit. E.G., a PDF reader or HTML file. Yes, an HTML file might include Javascript, but what the Javascript can do is tightly controlled (by correct implementations). Yes, a PDF reader might have a buffer overflow - but clearly that is a bug in the reader. But .desktop files can include ARBITRARY, UNMEDIATED command lines, which you're EXPECTED to run - that makes them fundamentally different.
Then, merely downloading and saving the file from the Internet does nothing - the user must then set the execute bit.
Of course, this presumes that unpackaging GUI programs won't just set the execute bit on programs without giving users a chance to deal with that, but that only requires careful implementation of a very few programs.
Posted Feb 18, 2009 16:19 UTC (Wed)
by hppnq (guest, #14462)
[Link] (1 responses)
But it gets worse, I think.
Gnome, and I am sure also KDE, already offers an interface for making files on the desktop executable. Desktop launchers are a special class of files, that only make sense in a desktop environment, and that, alas, can also be put on the desktop. The problem is, and remains also in your proposed solution, that to some users a script that sends out credit card data to some unknown website cannot be distinguished from a picture of grandmother reading the desktop specification bible, and that it will also prove a considerable challenge to these users to determine whether or not to set this executable bit.
The system, of course, does a perfectly good job of recognizing all kinds of files, and would certainly not execute files it does not recognize.
What seems a simple, straightforward solution introduces problems without removing the original problem at all: that a user can be tricked into thinking that file A is actually file B, or that file A is of type C. Your proposed solution for inadvertently running malicious programs is trivially circumvented by promising the naive user that making the file executable -- which you have made a standard action now, because there will be legitimate cases also -- allows her to install the new Tom Cruise screensaver.
Adding insult to injury, now, all launchers are a harmless waste of diskspace if I remove Gnome from my system, but not so in the proposed solution: they would remain executable even after removing the complete desktop environment (as in switching from Gnome to FVWM95) -- unless I of course also removed the new, decoupled interpreter, which would possibly result in many errors with a predictable solution, which opens up a whole new category of security issues. (And I do not just mean that in a few years, it would be like suggesting to remove Python from your system.)
It should be obvious that abusing an existing interface will never lead to a more secure system. The proper solution is suggested here already: let the user explicitly confirm that a certain program is to be run with a specific purpose. This is not a problem that is easily solved, it is much more difficult than it seems.
The proper stopgap, IMHO, is to allow launchers (interpreted as such) only in certain directories, and restrict access to these directories.
Posted Feb 19, 2009 15:51 UTC (Thu)
by dwheeler (guest, #1216)
[Link]
Clearly there is nothing that is foolproof. I think the key rule is that "to get the system into an insecure state, you must perform a special, unusual operation that is almost never requested otherwise, one the user would notice." (This is why Vista's whining is useless - it complains too often, training users to ignore it.) I think "setting the execute bit" can and should be a sufficiently "special, unusual operation" that it counts. "Please turn on the execute bit" should be something that normal users DON'T do, indeed, many GUI users wouldn't even know how to do it, and you could CERTAINLY put in a warning before doing it via a GUI. In contrast, "save a file from the web" is something that almost EVERY modern user does, so by itself "saving a file" should NOT subvert system security.
I agree that requiring that .desktop directories be in special trusted directories would work. However, that restriction makes .desktop files fail to work on the actual desktop, which reduces their utility greatly. And really, it seems bizarre that a .desktop file won't work on the desktop :-). But SOME change from the present seems necessary.
Posted Feb 13, 2009 10:19 UTC (Fri)
by hppnq (guest, #14462)
[Link] (9 responses)
What is unclear to me, is why this keeps cropping up as something even remotely connected to the problem. Yes, the fact that they are not real executables is extremely relevant, because like it or not, that is what the executable bit is supposed to indicate for all my other files. If the desktop launcher were not a file, it would have the exact same security problem, but we would not be having this discussion.
What the desktop people have assumed, is that launchers do not automagically show up on the panel. And on my system, they never do. I don't double click them, I click them, and they launch something that I put in there.
Icons on my desktop? You bet they have to have the executable bit set, at least on my version of Gnome.
Posted Feb 13, 2009 12:05 UTC (Fri)
by foo-bar (guest, #22971)
[Link] (4 responses)
Posted Feb 13, 2009 13:15 UTC (Fri)
by hppnq (guest, #14462)
[Link]
But, since launchers are not only special files to the DE interpreter, but also files on my filesystem and therefore interpretable by my shells, I prefer them to NOT be ordinary executables, shell scripts, Perl files or anything that can be run outside of the desktop environment.
Note that I am not saying that the typical desktop is a very safe place. Here, the problem seems to be that they can be run from different places within a desktop environment, which is not a brilliant idea. The solution is to keep things more separate: you will really not likely find ls(1) in /home/cracker.
All this, of course, has very little to do with serious security threats and defense mechanisms.
Posted Feb 13, 2009 16:08 UTC (Fri)
by jhardin (guest, #3297)
[Link] (2 responses)
Not quite. They can execute arbitrary _command lines_.
Perhaps this is a way to address the problem. Provide a list of the executables that the desktop manager is permitted to start via a shortcut.
"rm" for example would _not_ be on the list. Nor would "bash".
Posted Feb 13, 2009 17:28 UTC (Fri)
by bluss (subscriber, #47454)
[Link]
Posted Feb 17, 2009 17:08 UTC (Tue)
by gouyou (guest, #30290)
[Link]
Posted Feb 13, 2009 17:01 UTC (Fri)
by nix (subscriber, #2304)
[Link] (3 responses)
(Without said interpreter, the idea is useless.)
Posted Feb 16, 2009 8:57 UTC (Mon)
by aleXXX (subscriber, #2742)
[Link] (2 responses)
Alex
Posted Feb 16, 2009 10:11 UTC (Mon)
by hppnq (guest, #14462)
[Link]
Posted Feb 16, 2009 20:17 UTC (Mon)
by nix (subscriber, #2304)
[Link]
(Anyway, shell scripts cannot be interpreters for other shell scripts:
Posted Feb 13, 2009 12:33 UTC (Fri)
by tzafrir (subscriber, #11501)
[Link] (1 responses)
E.g.: what should happen if you mount /home noexec ?
Posted Feb 13, 2009 13:10 UTC (Fri)
by roblucid (guest, #48964)
[Link]
Do not allow direct execution of any binaries on the mounted file system. (Until recently it was possible to run binaries anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.)
For ~/bin to work for trad shell scripts and such, you need the file to be opened for processing by the exec-ed interpreter, in another filesystem.
Posted Feb 13, 2009 20:43 UTC (Fri)
by edmon (guest, #26395)
[Link] (5 responses)
Posted Feb 13, 2009 22:08 UTC (Fri)
by alecs1 (guest, #46699)
[Link] (2 responses)
Trolling and joking aside, this is too much talk. Smart people working on desktop standards can discuss on this and get a secure solution and avoid doing this kind of problems next time. Propositions where already made.
Posted Feb 13, 2009 22:28 UTC (Fri)
by gat3way (guest, #47864)
[Link] (1 responses)
I find another aspect of that article disturbing - the use of gksu to gain root. I never used it (being a KDE user), but now I made a quick look at it - IT IS ****** DISASTROUS!!!
You have the possibility to *remember* the root password. That's great - once you've entered it, anyone that got your rights can execute a binary as root. That's not all - this thingie is written plain wrong. It has for example format string vulnerability as shown here:
http://img99.imageshack.us/img99/8199/gksubz7.png
At least it is not a SUID binary, otherwise the consequences would be very bad...
I never knew that those KDE/Gnome devs could be such ignorant and irresponsible guys, even though I am a heavy KDE user myself. Quite embarassing...
Posted Feb 14, 2009 0:22 UTC (Sat)
by alecs1 (guest, #46699)
[Link]
This would solve for example the convenience securely enough when only one user has local access to the computer:
Reading the article on Wikipedia, Windows Vista got this right, and the few minutes I used my Vista I liked it very much: http://en.wikipedia.org/wiki/Comparison_of_privilege_auth...
Posted Feb 14, 2009 3:01 UTC (Sat)
by mikov (guest, #33179)
[Link] (1 responses)
Posted Feb 14, 2009 11:14 UTC (Sat)
by gat3way (guest, #47864)
[Link]
Posted Feb 13, 2009 21:52 UTC (Fri)
by purslow (guest, #8716)
[Link] (1 responses)
However, many people prefer the Windows way of having document launchers
Surely, the simple way to do this is to limit the apps which are allowed
The kind of Joe User who is ready to drop an unknown file on his desktop
Joe User could drop any genuine picture PDF etc onto his desktop
Isn't this the proper UNIX approach to solving the problem ?
Posted Feb 18, 2009 9:23 UTC (Wed)
by k8to (guest, #15413)
[Link]
Limiting the ability to add .desktop files to the system without specific effort is I think what you want. I don't believe "I dropped a .desktop file on the screen" should be sufficient to reconfigure the system, nor enable arbitrary commands to be run with a simple doubleclick.
Of course, I also don't think doubleclicking a program should launch it, but that's another discussion.
Posted Feb 19, 2009 8:23 UTC (Thu)
by aleXXX (subscriber, #2742)
[Link] (4 responses)
Alex
Posted Feb 20, 2009 10:42 UTC (Fri)
by nix (subscriber, #2304)
[Link] (3 responses)
I didn't think of #!/usr/bin/env xdg-open, but that works nicely. (I'm not
Posted Feb 20, 2009 19:53 UTC (Fri)
by biged (guest, #50106)
[Link]
The use-case I am familiar with is configuration management and site-wide installations. The calling process has PATH constructed to collect a carefully managed set of versions of programs together, and scripts work well when they respect the PATH.
Environment Modules (http://modules.sourceforge.net/) is a very usable approach. (The tcl implementation is the better version, in my experience.)
It comes down to control: the script user knows their needs and their environment, more so than the script writer. In a multi-user, multi-machine environment, a surprising wide variety of tool collections can be made to work, often on a monoculture of old distributions: in my case, RHEL3 until recently.
In a hardware or silicon engineering environment, being able to freeze and re-use a versioned collection of tools some years after they were originally current is very useful. I think it also has applicability in a software engineering environment.
Please, do use #!/usr/bin/env, even if it doesn't seem well-motivated on a single-user short-lived installation.
Posted Feb 20, 2009 23:17 UTC (Fri)
by mp (guest, #5615)
[Link] (1 responses)
Posted Feb 22, 2009 21:24 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Even worse than it seems
thanks fd.o
thanks fd.o
configuring your keyboard and screen with underdocumented HAL fdi XML
isn't clear and easy? What are you on?
for, whether it documents what your hardware is *capable* of, or how it's
*configured*, or as seems likely both in an ugly mess... and I'm not even
sure how to figure it out. There's no useful docs in the HAL source tree
nor the fontconfig one and this stuff isn't in man pages. *sigh*)
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Within just a few hours this article became my most visited blog post ever. Wow!
Right dude, I'm sure you had no idea what the effect of provactively-titled blog entries claiming security holes was going to be.
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
within the privilege system. The problem that the .desktop files tried to
solve was to have an icon and application title associated with an
executable file.
need of such things. Or if the executable format could contain such data.
clicked is not obvious.
Users can run all kinds of destructive things. The issue here is that a
user could run something without knowing it.
Follow up: How to write a Linux virus
/usr/share/applications/iceape-addressbook.desktop:Exec=iceape -addressbook
/usr/share/applications/iceape-composer.desktop:Exec=iceape -edit
/usr/share/applications/iceape.desktop:Exec=iceape %u
/usr/share/applications/iceape-mail-compose.desktop:Exec=iceape -compose
/usr/share/applications/iceape-mailnews.desktop:Exec=iceape -mail
/usr/share/applications/iceape-navigator.desktop:Exec=iceape -browser %u
/usr/share/applications/iceweasel.desktop:Exec=iceweasel %u
/usr/share/applications/gdmsetup.desktop:Exec=gksu /usr/sbin/gdmsetup
Follow up: How to write a Linux virus
> application title associated with an executable file.
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
- "icon"
- "icon_file_path"
- "icon_title"
- "file_extensions_handled"
- "menu_category"
ELF sections are easy to manage, i.e. you can add and remove them from every executable in an installed distribution, without risks about execution of the modified software.
In fact the problem is not downloading a random file from Internet, it is that doing so will silently change the ownership to the user - and so be trusted like any other file the user owns.
Maybe all files downloaded from Internet should be owned by "internet" username until their signature is verified, then they would change ownership to "fedora" or "debian" if it is a verified package, or some smart management based on the username/group.
Follow up: How to write a Linux virus
B. What about other formats?
- #! script
- a.out
- win32
- Java
Follow up: How to write a Linux virus
But what brilliance, no? To indicate that the icon is an icon, and to use an icon to do that. It's an Escher-icon.
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
in your file listing. And if you click on them permissions are respected. I
suspect that in most cases they don't represent applications that would
show up in a menu.
Lean mean and insecure. Your dpkg or whatever which now contains the icons
and executable would have some files bigger, but less files.
problem. .desktop files are particularly dangerous because they disregard
the permissions scheme, and are opaque in what they run. Downloading a
binary executable now would require setting the executable bit. Downloading
a tar requires extracting the file that could have the executable bit set,
finding it and running it. Having non trivial mechanisms to do that within
the gui would get rid of the non-expert user issue. The real solutions are
probably better handled below the gui level with SElinux or policykit type
stuff. As long as the gui launching respects the permissions, which it
doesn't now.
the executable. Essentially the launcher runs a quasi script that is not
subject to the permissions scheme of the os. Note the following link.
counterproductive? We end up with lowest common denominator trash. The
objections end up being something like "this isn't a real solution, so
let's stick with the blatantly insecure".
Follow up: How to write a Linux virus
> they show up in your file listing
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Add to the iceape binary these ELF sections:
Follow up: How to write a Linux virus
.desktop.chatzilla:
options:
-chat\0\0
.desktop.iceape-addressbook:
options:
-addressbook\0\0
.desktop.iceape:
filearg:
.desktop.iceape-navigator:
filearg:
options:
-browser\0\0
symlink /usr/share/applications/{chatzilla,iceape,iceapi-navagator,etc} to the iceape binary.
Follow up: How to write a Linux virus
Note that I still do not understand the general problem, if the .desktop file is executed under the "internet" user in the "internet" group, the virus can only modify "internet" files.
In fact the problem is not downloading a random file from Internet, it is that doing so will silently change the ownership to the user - and so be trusted like any other file the user owns.
Maybe all files downloaded from Internet should be owned by "internet" username until their signature is verified, then they would change ownership to "fedora" or "debian" if it is a verified package, or some smart management based on the username/group.Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
The user "internet" has access to the local screen (if the real user didn't do "xhost -"), and the sound card.
The browser downloads an untrusted executable file, keep it executable and set the set-uid bit and owner "internet", and put that on the desktop.
The real user can click on this icon and run it without checks, the worst which can happen is that all "internet" user files will have a virus.
That postcard with sound example can be viewed without problem.
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
yum/apt-get/whatever - should not be able to dictate how it is presented to the desktop user.
This because in the desktop metaphor, the appearance indicates how the system is going of 'open'
the file when you double-click on it. Allowing files which 'open' in the same way to have different
appearance breaks the methaphor and mislead the user, opening the way to lots of 'windowesque'
problems (windows allows executables to embed their own icons, and a number of virus exploited
this).
Alternatively, if you want files to be able to carry its own icon, then you should have no 'default
action', only show a pop-up menu with all possible actions.
from the internet (package managers can always reset it before execution). But for this to be
effective one should also hack perl/python/ruby/... interpreters to make them 'respect' the
executable bit.
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
> .desktop files should really be treated as scripts because that's exactly what they are.
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
making .desktop files executable
All of this seems not too hard to implement if you really put your mind to it but ranting on and on about it is the real path to go.
making .desktop files executable
making .desktop files executable
making .desktop files executable
making .desktop files executable
Easily solved - require that .desktop files be executable ("x" bit)
The only benefit to be had from inspecting an executable bit on an untrusted desktop file, is that it may indicate that the user has taken this action knowingly and on purpose. It seems to me that this is a very wrong assumption, one that should not be made at all.
Easily solved - require that .desktop files be executable ("x" bit)
Easily solved - require that .desktop files be executable ("x" bit)
Follow up: How to write a Linux virus
What is totally unclear is why double-clicking doesn't require .desktop files to have the executable bit set.
Follow up: How to write a Linux virus
These launchers cannot execute arbitrary code. You can click on them of course. Whether something bad happens then is a different problem, and because a DE is nowadays getting more and more capable of turning code into a running process, this does require some attention from developers and users alike.
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Brilliant, it can open www.pentagon.gov as well as /tmp/britney.png.
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
we'd need an actual binary for this job.)
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
download this , save it on desktop. click on it! :)
my wife pictures
NOW read new README file on Desktop
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
If you are in the high privilege group and want to execute some root command then press ctr+alt+del (invent a combination that only the kernel and xorg can read) and take absolute control on the cursor. Nothing but a local mouse can move the cursor. Show a dialog that says: "you are going to execute command_name. Click OK if you want to go on".
If an application wants to run as root, again, dialog "Please press ctrl+alt+del" to grab focus of click cancel, bla bla", then show the previous dialog where you click OK.
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
KDE requires you to authorise them & defaults to 'no'.
I always download to a dir ~/hold/ & open from there
with the app of choice, eg Xpdf Most or Gvim. The proper way to use
an environment with multiple desktops is to have different apps on them,
which take up the whole screen (or nearly), obscuring any icons:
app launchers belong on the panel or you can use something like Apwal
(which has long been my preference).
spread out all over their desktop, minimising them to the taskbar
& re-maximising them again all the time (I find that confusing),
so KDE etc need to protect against the ploy described by Foobar.
to be started via desktop icons. There would be a default list
in the KDE Control Centre -- eg Kwrite Kpdf Konqueror Kview Koffice -- ,
which the user could add to or alter subject to a Big Awful Warning !
eg I might alter the last two to Feh & OpenOffice & you could also add
scripts -- Bash Python etc -- , if you knew enough to want to.
would be unlikely ever to venture into the Control Centre
& if he ignored the Big Warning, there's nothing more anyone can do.
On multi-user systems, the Sysadmin could set it up to prevent users
from altering the default list of apps or accessing the KCC at all.
& when he clicked it would be opened by Kview Kpdf etc without hindrance.
If the file contained a (malicious) Python script, it would not be run,
as Python would not be among the default list of useable apps.
Why haven't the KDE devs -- whom I much admire -- dealt with this yet ?
Follow up: How to write a Linux virus
So I think having a set list is not what you want.
Follow up: How to write a Linux virus
http://lists.kde.org/?t=123438702300001&r=1&w=2
http://lists.kde.org/?t=123501789500001&r=1&w=2
Follow up: How to write a Linux virus
sure if the /usr/bin/env is actually required: how common is it to have
xdg-open anywhere else?)
using #!/usr/bin/env
Follow up: How to write a Linux virus
Follow up: How to write a Linux virus
used to allow scripts to be interpreters as well as to allow interpreters
to be located anywhere, but of course it can. :)
