| |||||||||||||
|
| |||||||||||||
Follow up: How to write a Linux virusFollow up: How to write a Linux virusPosted Feb 13, 2009 2:05 UTC (Fri) by Arker (guest, #14205)Parent article: Follow up: How to write a Linux virus
Has nothing to do with linux.
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*. :(
(Log in to post comments)
Follow up: How to write a Linux virus Posted Feb 13, 2009 3:50 UTC (Fri) by JoshK (guest, #56628) [Link]
Are there any projects out there doing anything different? It seems to me both the major ones (GNOME, KDE) and the minor projects (XFCE, LXDE,etc) all try to mimic the way Windows works, while the old style systems like OpenBox and Fluxbox are stuck in a rut of being "just" window managers.
Follow up: How to write a Linux virus Posted Feb 13, 2009 5:46 UTC (Fri) by dkite (guest, #4577) [Link]
If you select an executable in one of the file browsers, it will run it
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.
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
Follow up: How to write a Linux virus Posted Feb 13, 2009 8:02 UTC (Fri) by tzafrir (subscriber, #11501) [Link]
Same executable, different commands:
/usr/share/applications/chatzilla.desktop:Exec=iceape -chat
A non-trivial command for an executable:
Follow up: How to write a Linux virus Posted Feb 13, 2009 8:37 UTC (Fri) by roblucid (subscriber, #48964) [Link]
> The problem that the .desktop files tried to solve was to have an icon and
> application title associated with an executable file.
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.
Follow up: How to write a Linux virus Posted Feb 13, 2009 11:20 UTC (Fri) by dgm (subscriber, #49227) [Link]
Note that this will NOT solve the security problem, that is that any program can be disguised as any other. Also, this would require having a central icon db.
Follow up: How to write a Linux virus Posted Feb 13, 2009 12:38 UTC (Fri) by roblucid (subscriber, #48964) [Link]
Yes, so you have your allowed interpreters that understand the file formats. Now when someone saves a file as data, and it's not in your list, you don't legitimise it. People have to install a program, to run the pay load.
How is that worse than interpreters for handling mime types?
Follow up: How to write a Linux virus Posted Feb 13, 2009 15:34 UTC (Fri) by dkite (guest, #4577) [Link]
Great. A Windows Registry.
Derek
Follow up: How to write a Linux virus Posted Feb 13, 2009 11:42 UTC (Fri) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]
> The problem that the .desktop files tried to solve was to have an icon and application title associated with an executable file.
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.
Follow up: How to write a Linux virus Posted Feb 13, 2009 12:30 UTC (Fri) by tzafrir (subscriber, #11501) [Link]
A. how do you get multiple menu items from a single ELF binary?
B. What about other formats? - #! script - a.out - win32 - Java
Follow up: How to write a Linux virus Posted Feb 13, 2009 13:31 UTC (Fri) by efexis (guest, #26355) [Link]
How is this an issue? When does one build their menu out of the actual applications, not links to them? Oh, and win32 (or 'PE' as is the binary object model used for their exe 'n dll's) has containing multiple icons pretty well sorted and used.
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...
Follow up: How to write a Linux virus Posted Feb 13, 2009 14:59 UTC (Fri) by hppnq (subscriber, #14462) [Link] 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.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.
Follow up: How to write a Linux virus Posted Feb 13, 2009 19:00 UTC (Fri) by vonbrand (subscriber, #4458) [Link] 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.
Follow up: How to write a Linux virus Posted Feb 14, 2009 11:08 UTC (Sat) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]
Nobody said that the icon_file_path was an absolute path, it could be "application/textmode/editor/vi.xpm" and prefixed by default with "/usr/X11R6/icon", but can be overwritten by environment variable ICON_PATH pointing to the user directory...
Follow up: How to write a Linux virus Posted Feb 16, 2009 9:18 UTC (Mon) by dgm (subscriber, #49227) [Link]
Excuse me if I sound rude, but I would give up themeability (sp?) for security any day. Changing the vi icon is not even in my list of desired features.
Follow up: How to write a Linux virus Posted Feb 13, 2009 16:00 UTC (Fri) by dkite (guest, #4577) [Link]
Scripts, a.out could have a standard icon, as they do now if they show up
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.
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
Follow up: How to write a Linux virus Posted Feb 13, 2009 19:26 UTC (Fri) by tzafrir (subscriber, #11501) [Link]
> Scripts, a.out could have a standard icon, as they do now if
> they show up in your file listing
You just removed the icon from all of the Mozilla programs.
Furthermore, replacing a program with a wrapper script is a rather common practice.
Follow up: How to write a Linux virus 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.
Follow up: How to write a Linux virus Posted Feb 13, 2009 17:17 UTC (Fri) by iabervon (subscriber, #722) [Link]
Have the relevant section name depend on the basename of the executable; that's the usual way of having the same executable do different things when run. You just make a symlink to set it. The filesystem storage costs are probably less than the .desktop file anyway.
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.
Follow up: How to write a Linux virus Posted Feb 13, 2009 19:31 UTC (Fri) by tzafrir (subscriber, #11501) [Link]
Again, please find something that is at least good enough to cover the problems demonstrated in http://lwn.net/Articles/319122/ .
Follow up: How to write a Linux virus Posted Feb 13, 2009 20:46 UTC (Fri) by iabervon (subscriber, #722) [Link] Add to the iceape binary these ELF sections:
.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.
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.
Follow up: How to write a Linux virus Posted Feb 14, 2009 8:34 UTC (Sat) by ringerc (subscriber, #3071) [Link]
The performance cost of that would be horrifying, as it'd force the linker to do all sorts of unnecessary work whenever it executed any process. Like, say `ps', `ls', `as', `gcc', etc.
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.
Follow up: How to write a Linux virus Posted Feb 13, 2009 16:11 UTC (Fri) by droundy (subscriber, #4559) [Link] 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.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.
Follow up: How to write a Linux virus Posted Feb 13, 2009 17:08 UTC (Fri) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]
> The trouble is that the user of a process running an executable is not determined by the owner of the executable.
Unless sticky bit is set, I thought it was obvious to set it.
Follow up: How to write a Linux virus Posted Feb 13, 2009 21:32 UTC (Fri) by quotemstr (subscriber, #45331) [Link]
You're talking about set-uid, not sticky. The sticky bit has no effect on non-directory files on modern systems.
Follow up: How to write a Linux virus Posted Feb 13, 2009 19:35 UTC (Fri) by tzafrir (subscriber, #11501) [Link]
What is "internet"? So the browser should not be allowed to save files on the disk? Any time you download a file you'll have to explicitly enable it? So you'll get used to that and enable it for that new "harmless" desktop file.
Follow up: How to write a Linux virus Posted Feb 14, 2009 11:34 UTC (Sat) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]
The user/account "internet" has, like any user on Unix, a directory usually named /home/internet, it can do whatever it wants there (like installing any kind of virus, or doing rm -rf .*). You can set any limit for this untrusted user by ulimit.
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.
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.
Follow up: How to write a Linux virus Posted Feb 19, 2009 14:53 UTC (Thu) by mrshiny (subscriber, #4266) [Link]
So you're basically suggesting a user run their browser under a different user account, to sandbox it. One disadvantage I can see is that many people would never bother to change the ownership of the "internet"'s files and, if infected, would end up with a lot of data at risk for loss/theft. Also, if a file is not de-sandboxed in a timely fashion, a later infection can modify data the user has already "vetted". This increases the risk of infected files escaping the sandbox, when the user decides they finally want to copy that mp3 to their music folder.
Follow up: How to write a Linux virus Posted Feb 16, 2009 16:55 UTC (Mon) by salimma (subscriber, #34460) [Link]
OS X does something like this -- downloaded executables are marked as being untrusted, with a record of their download time, and users are warned the first time they are launched. A malicious app can disguise its icon all it wants, but cannot circumvent this.
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.
Follow up: How to write a Linux virus Posted Feb 20, 2009 11:02 UTC (Fri) by bockman (guest, #3650) [Link]
I believe that the basic issue is that a file - either downloaded by internet or properly installed by
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.
Oh, and of course it is always a good idea to remove the executable bit from anything downloaded
|
|
||||||||||||