Restricted Software Torrents

Not to say I am more right than anyone else on this topic, but again using MCX will allow you to restrict applications running by full file path. This means you do not have to maintain a list of known restricted applications. Furthermore, what is stopping a user from renaming a bit torrent client to TextEdit.app? Then guess,what, it is approved.

I just feel if you need to restrict what runs on your computers in your environment and since OS X allows for tons and tons of self contained applications to run, restricting by file path is the best/most efficient method. As long as the users cannot write to the Applications folder itself, then they cannot install and run their own apps.

There are a few caveats in this method, so it is not perfect, things like:

1 - apps that need to run any sort of self updater cannot be ran by the user if they need to write to any file in /Applications

2 - apps that need access to other apps outside the /Applications folder must also be approved, things like CS4 from Adobe need app paths in /Library/Application Support approved as well

3 - if there is an app in the user's home folder you may have to use sym links, however I feel that is bad design by the developer

At one point in time I was using an approved/restricted software list in OD and using MCX to enforce it. Then I was using digital signing as well. It was very annoying, and a lot of leg work. So in the end I went with MCX restricting file paths, setting proper permissions, and then doing some creative packaging with developers do dumb things like put apps in non standard places.

Just my opinion is all.

Thanks for reading,

Tom


I've said it once… I'll say it again… This is a game of whack-a-mole. Kill this stuff at the firewall and it makes a whole lot less work for you :)

j
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

Here here

Criss Myers

Firewalls don't stop MAME emulators, video games, or anything else
unless it tries to go out on the net. Plus my users, take and use their
machines off campus. There is no direct end all be all answer, the
security of it should be in layers. You should use local management
with firewalls, in my opinion.

heh. So I was still right with my "kill it at the firewall" statement :)
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

Somebody buy this guy a beer?!

Here are the processes we block in AppState Labs

We can not block these at the perimeter as Faculty can and will use some of them for legitimate purposes. We do run Red Lambda as a monitor and can restrict if needed at the perimeter on a case by case basis. The reports from RL give us a good list of what to block

LimeWire
Cabos
LH-ABC
Azureus
Wuala
BitTorrent
fileSharingMUTE
amule
amulegui
Acquisition
Transmission
FrostWire
wrapper-macosx-u (FreeNet)
uTorrent
kazaa
k-litepro (Kazaa Lite)
Poisoned
SolarSeek
Xtorrent
iTerm
Vuze
Folx
Opera
eDonkey
Kademlia

I'd say the other piece is to have a clearly defined acceptable usage policy for your users and make sure they're both aware of it as well as any consequences for violating it. (Admittedly, this is easier in a business environment..)

Someone who is busted to HR/administration/etc is a lot less likely to continue trying to run prohibited software.

What do you when the service is called JavaAplicat (frost wire, Azure, bittorent) what would be the correct way to kill the service?

In that case it may be easier to do a "kill on sight" policy where you have a smart group that looks for particular application names. If it see it, trash it. As I mentioned previously, I think your firewall is a good place to try and block that sort of traffic.