Sean Middleditch

Trojans (the malware, not the happy hats) are sometimes cited by groups such as PMK and alternative installer frameworks as a problem for systems like autoconf or common Linux package formats.

The argument is that a configure script or a installer script could easily contain malware, and that this malware will infect the system when the installer is run as root.

I can’t figure out what is wrong with these people.

It is absolutely no more likely or easier to hide malware in an install script than it is to hide it in the application’s binary or source code. Sure, an installer for Foo can’t break my system, but as soon as I run Foo itself, it could do just as much damage.

The usual counter argument here is that the installer runs as root, and the application does not. Avoiding the fact that most the alternative installer systems allow for running a binary, and also the fact that many sysadmins are not going to shirk away from running a config/setup tool as root if the app “requires” it in order to work after install (because the install itself couldn’t, eg, update an application-specific DB after install), is avoiding root malware really much of a benefit?

Let’s say an installer, running as root, trashes my system and deletes all my files. Reinstalling any decent Linux distro only takes 15 minutes, tops, and getting it tweaked and configured shouldn’t be more than an hour for any reasonable person. The real loss is to all my important files. Records, source code, email, and anything else a person might keep on his computer. If the Foo application itself has malware, and I run it as my user, it can do all of that important damage just as easily as the UID 0 installer script could. I see no benefit from refusing to run arbitrary scripts at install time, because my actual valuable data is still at risk, and all I gain is the need to do extra manual work to install many apps since they can’t configure themselves at build/install time.

The second counter argument in this debate is that we have multi-user systems. In theory, root is more dangerous on such systems. In truth, it is, because one mistake as root wipes out multiple persons’ valuable data, not just one. However, this doesn’t much hold for installers.

There are three general setups, broadly speaking: there are single-user machines, like the majority of home desktop Linux users, in which there is only one real user of the system, and thus usually only one user account and the root account. There are then the rarer true multi-user home and small office desktop Linux users, in which several people share a computer. One or more of them are the “Linux guy” who knows how to work the thing and he has the root password. Finally, there are the large deployment setups, where there are many machines, many users, and a few sysadmins.

The first setup - single-user machines - are already covered. They’re just as at risk even if installers can’t have trojans.

The second setup - standalone multi-user machines - are barely more protected. If the sysadmin installs a new app, it’s likely that all users of the machine will use it. Furthermore, such systems rarely have things like file-system quotas and the like in place, so one bad user (or one user running a bad app) can still render the disk full, the machine unusable, etc. Most systems grant read access to user home dirs, and most office sweets don’t set modes on documents for users, so users still end up with sensitive data in a world-readable state. These very, very common setups are still ripe for data-theft trojans, and can still with some (ill-)luck allow for destruction of work or data.

The final setup - large deployments - are hopefully no more protected. Sysadmins for such networks should be testing applications before deploying them. They should be going through levels of care and scrutiny that the average home user - even one who’s an experienced sysadmin - usually doesn’t bother with. They should only be installed software from trusted sources, checking signatures, etc. If they don’t, then it is possible that a trojan in an installer could wreck havoc after infecting an NFS volume or the like. However, many careless sysadmins are just as likely to run the program itself to test that it functions, or just run random scripts or utilities as root from the web.

It’s fairly clear that there is little real, practical benefit to efforts to remove installer trojans.

While projects like PMK have many fine qualities, the oft-cited advantage of being free of configure script trojans is just hot air. These projects should focus on advertising their real strengths instead of phantom ones.

I truly despise the phrase, “that smarts!” If something hurts, it’s probably because you were doing something stupid. The phrase should be, “that stupids!”

I’ve posted a lot about the difficulties of getting a true networked client written in JavaScript. The “AJAX” stuff is great when the client wants to pull some data, but high-latency and unreliable when the server wants to “push” data to the client.

Thankfully, there is a spec for server-sent DOM events, which allow a script to open a connection to a server and receive streamed messages (events). Combine this with AJAX for sending messages to the server, and you have a fairly usable system, if not as usable as a duplex event passing mechanism.

However, Mozilla/Firefox does not support this feature. There’s a preliminary patch available, but it needs work by people knowledgable in Mozilla’s internals to finish it off.

https://bugzilla.mozilla.org/show_bug.cgi?id=338583

If you’re interested in having web apps that can truly communicate with a remote server efficiently, vote for this bug. Or, if you have knowledge of Mozilla’s internals, and you are really really awesome, improve the patch to help get it accepted. :)