I once wrote a kernel extension that intercepted any and all file open()'s on OS X. If the application in question was opening a file that it was not whitelisted to do so, it would bring up a modal dialog box asking whether or not this application should be allowed to open this file.
It was basically a firewall on the kernel level.
It worked splendidly, however, I was never able to gain any traction in marketing it. That was back at around OS X 10.4 now. I've been waiting for another company to come along with something similar - since it really does seem a comprehensive way of blocking viruses (albeit more suited to more advance uses). I'm still waiting for something like that.
That is an example of a mandatory access control (MAC) framework[1]. SELinux[1] is a MAC for linux systems and is very effective if the user doesn't disable it due to frustrations over false positives or due to true positives that are viewed by the user as false.
OSX has discretionary access control, which can be configured to be a full MAC[3].
Starting in OS X v10.5, the kernel includes an implementation of the TrustedBSD Mandatory Access Control (MAC) framework. A formal requirements language suitable for third-party developer use was added in OS X v10.7. Mandatory access control, also known as sandboxing, is discussed in Sandboxing and the Mandatory Access Control Framework.[4]
There is MAC framework inside MacOS X kernel, but it's only for Apple usage. Developers arent' supposed to use it, because Apple states that it has no ABI stability and it can change unexpectedly from version to version. That is probably why it's not used by any commercial software (or it's so rare).
Instead, Apple designed a KAUTH framework, which is way more limited than MAC, but can be used to implement some features that will be stable across kernels (it has ABI stability). There are already some AVs that are using KAUTH.
Yes, the file access part of this product is exactly what I wrote too. They even made it with just the same codebase, inside the bundle "HandsOff.kext" is where all the action is. It's commendable that these guys have made it & kept it going and have it running as a product. It is so much more difficult than it initially appears. One of the first things that you come up against is you find out that at the kernel level, there are thousands of open()'s occurring system wide a second. Managing that in linked lists in the kernel without creating a speed or memory hit is the initial challenge. Then the other thing you come up against, which is a much greater challenge, is avoiding deadlocks by blocking open()'s to the wrong process.
However, if a technical user is using the product, it makes security 100% solid. You can literally intentionally download and run any virus, with full confidence that you can easily stop it from doing anything you dont want it to. Since a dialog box is created before it can read or write to any file, there is literally nothing it can do without your permission.
It's also useful for monitoring what an installer or app is doing to your filesystem, exactly what files it is touching as it goes along, and also how to thoroughly uninstall it if you want to.
I have been meaning to make a cut down version just for the filesystem monitoring and as an uninstaller that works 100%. You can even make an uninstaller that not only uninstalls all files that were created alongside the file you choose, but also any files that were created by any of those files (by logging the paths of the open()'s with O_CREATE by any of those files)
> You can literally intentionally download and run any virus, with full confidence that you can easily stop it from doing anything you dont want it to. Since a dialog box is created before it can read or write to any file, there is literally nothing it can do without your permission.
What about a virus that reads your keystrokes or screenshots your screen and sends them to the Internet? Or a virus that spams or does DDOS attacks?
That's the beauty of it. Take the keystrokes example you gave. Run it. Allow it to monitor your keystrokes (by clicking "Allow" when it's doing stuff related to that). Allow it to create the file logging your keystrokes, if you want (granting it write only access when the dialog box comes up). But after you have toyed with it, you might stop it at the point when it attempts to read from that file, in order to transmit it over the internet, or whatever it's going to do with it.
Same with the screenshots. You'd allow it to do whatever you feel like, but you might stop it when it tries to actually create the screenshot file, but allow it to do everything else in order to monitor its behavior. And since it's all in real time, with dialog boxes coming up for each of its actions, it makes it quite interesting to do so.
Isn't it dangerous to assume all malicious programs will use scratch files before communicating across the network? Won't you miss programs that use purely in-memory structures?
Yes, it is. And that was just a simplified example. In practice if you were running something you were very distrustful of, you would block access to almost all of its file access. You also wouldn't leave it running for long enough to feed it enough keystrokes to get you into trouble. But even if you did, you would catch it with all the file opens (and network connection open's) before it could transmit your keystrokes and get you into trouble. In practice many file open()'s are required to perform any function.
I’ve been using Hands Off! for the functionality for the past few years, but if I had known that the functionality was based on your kernel extension, I would’ve switched away from Hands Off! in a heartbeat (I already get the firewall features of Hands Off! from Little Snitch, so the only reason I use Hands Off! is for the disk access control feature).
Out of curiosity, could you provide a link to the website advertising your kernel extension (if it still exists)? As an OS X user, I feel pretty bad that I wasn’t aware of its existence (I would’ve certainly recommended it to my friends).
Sorry for being unclear, I didn't mean to say that it was based on my kernel extension. I meant to say that we both based it off of the same kernel extension. The extension in question is called kAuthORama and is provided by Apple. (note: I'm not 100% sure that they did use that, that was just an educated guess).
It was based on a port of OpenBSD's PF firewall and let you set fine-grained permissions on file, network, and registry access. It's a painful training process for newly-installed software (lots and lots of prompts) but I haven't seen anything else come close to what it offered. I wonder if that pain is why they seem to have abandoned it; at some point the average user would end up just uninstalling it or clicking "Allow" for every prompt.
Once up and running, however, you could do some really cool things such as giving a process read-only access to its installed directory plus the ability to read/write to a specific folder you store that program's documents in. Attempts by the program to read outside those directories would be rejected, with mixed results (from gracefully handling it, to endless alert dialog looping, to crashing) depending on how well the software was written.
When I read this, I thought, "Hey, that sounds a lot like Little Snitch but for disks." Then I read below that LS' main competitor, Hands Off!, seems to have that functionality. Very interesting...
I did something similar for a Computer Security class back in the day, but I did it from userland using dylib injection, and did it as a PoC of the malicious things you could do without getting root.
Once you've intercepted read() and write(), you control almost everything. One of the demos I did was injecting content into HTTP responses. Fun project, very glad I didn't ever share the code for it :)
You've basically written a HIPS - Host Intrusion Prevention System, or at least a base layer of it. Antiviruses on Windows are popular to have this kind of protection, I don't know of commercial solutions for other systems.
It was basically a firewall on the kernel level.
It worked splendidly, however, I was never able to gain any traction in marketing it. That was back at around OS X 10.4 now. I've been waiting for another company to come along with something similar - since it really does seem a comprehensive way of blocking viruses (albeit more suited to more advance uses). I'm still waiting for something like that.