Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'PEBKAC: Why hard links/aliases aren't the solution' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
PEBKAC: Why hard links/aliases aren't the solution
Authored by: robophilosopher on May 18, '04 10:58:43PM
There are two ways we can approach this kind of "malware." The first is to do things like this, or like aliasing 'rm,' which is to say, temporary fixes to prevent specific abuses. These 'fixes' will fail as soon as a Trojan runs
find ~/ -type f --exec cat {} \; 
(disclaimer: I'm not 100% sure on my syntax there, particularly how that redirection will work in the --exec clause. plus, a dd would be more effective, right?) or similar instead of rm. You have to think anybody with half a brain writing this sort of bad stuff will be using actual interaction from the program, rather than system calls or shell commands. The more important issue is resisting viruses and trojans' entrance points. This is what mac is fairly good at, what UNIX is great at, and what gives OS X the track record it has against viruses. (Yes, Windows is a bigger target, and that's a contributing factor, but I stand by my statement.) Fixing the 'problem' that is involved in much of the (potential) malware I've seen is to maybe introduce a GUI-level warning when executing a program that has an "open with" extention, or something like that, to prevent un-vigilant people from doing un-wise things...

You create hard links, I can write to the inodes. You don't run my program, I can't do squat.

PS: check acronymfinder for the subject line if you're interested.

[ Reply to This | # ]
PEBKAC: Why hard links/aliases aren't the solution
Authored by: SOX on May 19, '04 10:24:37AM

How does one write to inodes. Usually one writes to files that get unlinked before being written, preserving the hardlink.

[ Reply to This | # ]