The premise is this:

I have an app which has been set in its code to only run on OS X versions 10.4 to 10.9.2. (When I try to install it, it gives a message "This version of ____ is for Mac OS X 10.4 to 10.9.2."). I have updated to 10.9.3, and the developer just needs to update the app to fix this restriction in his tool.

I'm actually in contact with the developer, who says he is 'too busy' to work on the app or issue an update right now.

I worked out that the app is just reading /System/Library/CoreServices/SystemVersion.plist to determine OS version, and I managed to bypass its installer restriction by temporarily editing the file using this guide. But after reverting the plist values to 10.9.3 and restarting the system to start (hopefully) using the app, I saw that it even checks SystemVersion.plist to even run as well - not just during installation.

I'm worried that if I keep SystemVersion.plist at 10.9.2 indefinitely it would ruin other parts of the system such as App Store updates and the like.

So my idea now, is to try and find some method or tool, to block the app from being able to even read SystemVersion.plist entirely - think of it as a 'file system' version of Little Snitch if you will - just some way to create custom rules, for specific processes, that disallow read and/or write access, to specific files/folders in the system.

Maybe it would just cause the app to throw an error and not run at all (I could probably test this by temporarily moving the plist file to Trash for just 30 seconds while trying to install/run it) - but in either case, I think it's a really useful thing to be able to have, for powerful security purposes - just like the custom-blocking network access for apps in Little Snitch.

So is there some awesome third party tool, or even native OS X / Xcode tool, that can do this? Any insights as to what would even need to happen anyway, system/programming-wise? Tweaking with 'Sharing & Persimmons' for a file in Finder lets me control user access, but not process.

  • 1
    What's the value in /Applications/APPNAME/Contents/info.plist of <key>LSMinimumSystemVersion</key>? Does one exist?
    – njboot
    May 18 '14 at 9:37
  • Gah - actually, it's a prefpane 'app' (didn't realise it was as it sits in the os x menu bar anyway) - will try to work out now the location of its files and/or if it's even got such a plist file inside it.
    – user46942
    May 18 '14 at 11:45
  • Update - within the .prefpane file, both its main Info.plist and the Info.plist within the nested .app file inside, don't have such a string. Originally checked for it in the installer file anyway, in the installer the code for checking OS version appeared to be within the compiled Mac executable file itself.
    – user46942
    May 18 '14 at 12:09
  • attempt to add the following to the info.plist: <key>LSMinimumSystemVersion</key><string>10.6</string> #see if that helps. I'm not providing an answer because I'm not sure if it would work.
    – njboot
    May 18 '14 at 12:19
  • The problem is, the app is enforcing a maximum OS version too. Does the LSMinimumSystemVersion deal with that, or only minimum? In fact, the app actually states a specific range (and I'm guessing it enforces both ends, since it certainly does the upper) - ah and actually I think I remember trying adding this string with value 10.9.3 to the installer .app file (some days ago) and it didn't work, so I'll conclude for now, that that wouldn't work on the .prefPane either! :/
    – user46942
    May 18 '14 at 12:28

You could just use the built-in sandboxing features of Mac OS X.

Create a custom profile that limits access to the SystemVersion.plist file, using syntax like this:

(version 1)
(deny file* (literal "/System/Library/CoreServices/SystemVersion.plist"))
(allow default)

Save that as for example ~/myprofile.sb and then run your program like this:

sandbox-exec -f ~/myprofile.sb "/Application/My Program.app/Contents/MacOS/My Program"
  • that sounds brilliant, but I just realised, it's actually a prefpane 'app' - wonder if it can still be sandboxed?
    – user46942
    May 18 '14 at 11:47
  • I guess you could just start "open -a system\ preferences" using sandbox-exec to achieve that goal.
    – jksoegaard
    May 18 '14 at 12:37
  • Thanks for that, I'll start off with trying it on the installer .app as a simple first test - I'm getting an error, 'unbound variable: deny', though :/.
    – user46942
    May 18 '14 at 13:59
  • Check the documentation for the correct syntax for the whole policy file - or start from one of the examples. I was just describing the specifics for limiting access to that file.
    – jksoegaard
    May 18 '14 at 14:18
  • 1
    Sadly, sandbox-exec is marked as deprecated in the current Mojave release. It seems that Apple was not able to make sandbox useful without making the sandbox programs useless.
    – Pat
    Feb 14 '19 at 19:27

Hands Off app has this feature:

Monitoring disk access

Applications present on your computer can freely read, store or erase information on your computer without your knowledge. Using Hands Off!, you can monitor and control disk access from all applications as to prevent them from obtaining confidential information, erasing your data or storing cookies.

And it happens to include the network firewall feature of Little Snitch.


Little Flocker, a tool that restricts apps and system processes access to files without permission. He was unable to talk details, but recently F-Secure, a leading security developer and analysis company, announced its purchase of Little Flocker, which it’s rebranded as Xfence.

MacOS Catalina now has this similar feature:

Data protections

macOS Catalina checks with you before allowing an app to access your data in your Documents, Desktop, and Downloads folders; iCloud Drive; the folders of third-party cloud storage providers; removable media; and external volumes. In addition, you’re asked before an app can perform key logging or capture a still or video recording of your screen.

You must log in to answer this question.