The second issue was to avoid tripwire or similar tools. These tools usually cover exectubles like ssh, login etc.. but do not cover motd if the system changes it a lot as it is not something you are normally worried about it changing its checksum. And normally they cover finding new executables in /usr/local/bin etc so you want to be careful.. but they usually do not cover home directories.

With 10 years experience.. we could just change .bash_profile to include $HACKER_HOME/bin on everyone's home directory and have them run passwd or other rooted binaries... However the issue was more on collecting information on how user education was going versus actually doing bad things.

> A simple example: wouldn't it be much easier if you didn't use the lock on your front door, no need to worry about taking the key with you, no need to put the bag with groceries on the doorstep while digging up the key....

If you want the easiest to use system in the world to be rock secure, you are of course toasted. But if you want reasonable security in a system reasonably easy to use, there can be some discussion. Of course, adding development cost into the equation makes it harder. But to say "I only cater for the uneducated, some functionality can be forgone if most Joe users don't need them" can make it a easier.

> I agree with you that security has been undervalued by major Operating System vendors, but even Microsoft is working very hard on fixing that.

If you can enlighten us about what has been done by MS to prevent social engineering, it can be very constructive.

> About your proposed social engineering attack: the post-install script of the rpm or dpkg can just copy and activate the rootkit that's hidden in the package... nasty nasty nasty.

By "every package is in its sandbox" it means even the post-install (or whatever) script is running in its own sandbox, and if a program has been installed in global space for others to run, that program is under a sandbox that never include more than the combined power of the user and sandbox of that package. Everything, like installing a file in "/bin" or creating a cron job, can only be done under the management of dpkg/rpm. Other tweaking might be required, this need to at least give dpkg/rpm a perfect picture to clean up any mess produced by any package.

Of course, this is just out of my imagination. Any system that provides equivalent security is probably just as useful. It is not easy to develop such a system, at all. One must think about how programs are going to interact, how they are going to access user data, and there must be some serious research on how these things cannot be turned into attack vector. In a world where the threats are not there or are seldom seen, these will never happen. But in a world where threats are the norm, there are definitely incentives.

> Is there an easy way to prevent these kind of social engineering attacks; nothing that beats education.

Education can be "easy" to a single individual, it is hard to ensure education to a huge population, all of them from different countries and hence different law systems and values. In fact I believe it isn't going to work at all. Even for well educated people, it is sometimes very tempting to install something that they really shouldn't, and it can be real hard for them to know whether something is safe to install. And the black hat only need a few percent of the network population to have made a wrong decision before they can build a huge botnet. In such hostile environment, we simply cannot count on 90% of the people won't make a wrong decision during at least the first half of the life of their OS install!

Problem is, people are frequently asked to install a program, to the point that most people will not think that it is a security problem. Except it is. And people frequently see packages floating on the web, and many claims to do useful things that they want to do. And in most cases these claims turn out to be true. To the point that most people will trust that the thing they found will be among them, except they might be wrong. If we create a system to "look safe", it needs to actually be safe. Our current systems "look" safe, but they aren't.