|Home » Learning Curve
Of Data Mining, Rootkits & Spotlight
Spotlight's underlying fsevents technology isn't as broad as desired.
A rootkit is the worst thing that can happen to any computer user and a nightmare for the network administrator. Rootkits by their very nature try to hide their presence.
Trojans of all sorts try to mine data off target machines, looking for passwords and account numbers to 'phone home' with.
Both represent a real threat.
OS X 10.4 Tiger's Spotlight uses the underlying 'fsevents' technology. The device file fsevents records changes in the file system. This would ordinarily be enough to thwart compromises, but the technology was customised for use by Spotlight and some 'red alert' events are neither recorded nor reported on.
fsevents is a new thing with Apple's OS X Tiger. It's what Apple 'invented' to get their Spotlight running. Of the 29 BSD/Linux kernels listed at watson.org, only the three that have to do with Apple proprietary code list it.
The fsevents interface can be found at the soon to be defunct OpenDarwin site.
The key to fsevents functionality is found in the first few lines of the header file.
// Event types that you can ask to listen for
#define FSE_INVALID -1
#define FSE_CREATE_FILE 0
#define FSE_DELETE 1
#define FSE_STAT_CHANGED 2
#define FSE_RENAME 3
#define FSE_CONTENT_MODIFIED 4
#define FSE_EXCHANGE 5
#define FSE_FINDER_INFO_CHANGED 6
#define FSE_CREATE_DIR 7
#define FSE_CHOWN 8
#define FSE_MAX_EVENTS 9
#define FSE_ALL_EVENTS 998
#define FSE_EVENTS_DROPPED 999
You register with the system that you want notifications and then it sends them back to you. [FSE_EVENTS_DROPPED is very important. fsevents has but a single buffer and can often can be forced to drop everything. Not fun - but when the technology is used only by Spotlight it only means a bit of noisy wear and tear on your hard drive. Ed.]
Look again at the notification codes. You get notifications of created files, deleted files, stat info changed, renamed files, modified files, exchanged files, Finder info changed, directories created, ownership changed, and of course all notifications being dropped.
fsevents does not report back on file accesses. It could - it's operating on file system driver level - but Spotlight doesn't need that information and so it's been omitted.
Will fsevents help protect you from rootkits and data miners? It depends. And hinges for the most part on Apple's obstinacy in using a file system they admit they know to be incompatible with Unix.
As with NTFS, you can reset all time stamps with HFS. All of them. There are five: attribute changed, accessed, fork modified, created, backed up.
The 'created' is what HFS gives 'Unix' if Unix wants the 'changed' field. HFS lets you modify this programmatically.
This means there are rocks and hard places for both the alert user and your wily neighbourhood rootkit when running an Apple file system as opposed to a Unix file system.
It also means HFS is a tangible - and incurable - security risk. Yes, good rootkit code is going to try to first 'get root' and then keep it - but it has to 'get root' first. The HFS APIs let you alter sensitive file system information without privilege escalation.
fsevents will never tell you what rogue programs are snooping at as long as they don't modify things. Spotlight could ask fsevents for that data and fsevents could be programmed to return such data, but Spotlight doesn't need it so you don't get it. Spotlight's only interested in changes on disk - even if a user wants to find out what data has been mined from the system.
If a rootkit or trojan simply goes in and mines the data, fsevents doesn't see it.
Given the choice, OS X users should let Unix people work on security and let Apple play with HFS.
In a permanently unconnected environment.
Copyright © The Ian Malcolm Research Institute. All rights reserved. Used by permission.