Block Execution of Specific JAR

[DJLC]

I work in a school with a 1:1 MacBook program. Recently, we've found students running pirated versions of Minecraft by executing a JAR file.

Naturally we have app restrictions in place via Profiles, restricting anything that's not in /Applications. But it seems they can execute the JAR from anywhere.

Is anyone aware of a way for us to block the execution of JAR files, preferably via Profile Manager?

 

[dyt1983]

edit: To remove personally identifying information not relevant to the thread.

 

[DJLC]

We do need a JRE; many educational web apps rely on it.

Although I did just solve my problem with zScaler. Blocked the specific AmazonAWS URL that serves the updates. Now the JAR launches, fails to connect, and errors out.

For anyone else looking to do this, we just blocked...
.minecraft.net
.mojang.com
.mcismyfriend.ucoz.com
.s3.amazonaws.com/Minecraft.Download/launcher/launcher.pack.lzma
(in zScaler parlance, beginning a URL with a . indicates a wildcard)

To be clear, I certainly do wish we didn't have to fight this fight. But I highly doubt these are legally obtained copies of Minecraft. Until kids bring me receipts, we're blocking it as a whole.

 

[chown33]

Another possibility is to remove the app that runs JAR files.

I'm pretty sure its name is something like "JAR Launcher.app", or something similar. It's typically located in /System/Library or /Library. Its exact location may vary depending on your OS version, whose JRE it is (Apple, Sun, Oracle), and maybe which Java version.

Basically, double-clicking a .jar file launches the app, which then runs the Java classes in the jar. So if you removed or disable the app, then double-clicking jar files won't work. The app isn't used to run Java in browsers; it only runs standalone jar files.

Industrious students may find a way around this, so blocking the URLs is still worthwhile.

 

[DJLC]

Ah! I didn't even think of that one.

I'll block execution of that app with a Profile update. Many thanks!

 

[dyt1983]

edit: To remove personally identifying information not relevant to the thread.

 

[DJLC]

Conveniently Terminal is also blocked in the Profile. And none of the kids have admin access.

And to further guard against anything, I was able to lock single user mode without having to set a firmware password on each one individually. Just created a login script for the root user — if it detects single user mode, it runs fsck twice and reboots. Of course they *could* escape out of that, but the chances of them 1) getting to single user and 2) knowing how to escape are pretty low IMO. Also saves me some time when troubleshooting.

I think we're switching to iPads for the 1:1 next year. OS X is like swiss cheese in this sort of environment. (Not that Windows is any better, either.)

 

[chown33]

Yeah, but it's quite easy to run them from the command line, so blocking the relevant URLs is part of a complete solution.

I agree on both counts.

Even if Terminal is blocked, they could use a Run Shell Script action in Automator, or a 'do shell script' command in AppleScript and achieve the same thing. Making /usr/bin/java executable only by root (or by no one) can avoid those (the chmod command). If there's no java command to run, then Java can't be launched.

There may be additional holes in the "swiss cheese", such as an exposed execute-to-all command located in the installed JRE folder. Those would need to be searched for.

The OP should plan on managing this as an arms race for a while, i.e. setup some kind of monitoring to look for infractions or even possible ones, and then work out how they're getting around the existing restrictions.

To some extent, the sophistication of the evasion tactics will depend on the age of the students. I'd expect high school or college students to routinely work around any restrictions, perhaps as often as monthly. Grade schoolers might defeat the restrictions less often, if at all, but I wouldn't discount it entirely.