Preventing .Apps from being copied

[Clinton Blackmore]

Greetings.

We have some problems when users copy a .app folder to their desktop
when trying to put it on their dock; specifically, this prevents
network users from logging in. Also, I'm aware of another system
administrator who wants to prevents students from copying .apps to
their USB drives.

I'm just probing the water with crankd; I was there for the MacWorld
session and this appears that it might just be the tool for the job.
I got the Socks demo to work, and using similar instructions, have got
things in order for running crankd to try out my script, er, module
without root privileges. I should probably mention that I am new to
PyObjC (and ObjC).

So, ~/Library/Preferences/com.googlecode.pymacadmin.crankd.plist
contains

-----

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://
www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSWorkspace</key>
<dict>
<key>NSWorkspaceDidPerformFileOperationNotification</key>
<dict>
<key>command</key>
<string>/bin/echo &quot;File Operation&quot;</string>
<key>method</key>
<array>
<string>CopyBlocker</string>
<string>onFileOperation</string>
</array>
</dict>
<key>NSWorkspaceDidWakeNotification</key>
<dict>
<key>command</key>
<string>/bin/echo &quot;The system woke from sleep!&quot;</string>
</dict>
<key>NSWorkspaceWillSleepNotification</key>
<dict>
<key>command</key>
<string>/bin/echo &quot;The system is about to go to sleep!&quot;</
string>
</dict>
</dict>
<key>SystemConfiguration</key>
<dict>
<key>State:/Network/Global/IPv4</key>
<dict>
<key>command</key>
<string>/bin/echo &quot;Global IPv4 config changed&quot;</string>
</dict>
</dict>
</dict>
</plist>

------

And the file symlinked to ~/Library/Application\ Support/crankd/
CopyBlocker.py contains:

--------------

from crankd import BaseHandler
#import socket
import os
#from PyMacAdmin.SCUtilities.SCPreferences import SCPreferences


class CopyBlocker(BaseHandler):

def onFileOperation(self, aNotification):
print "OnFileOperation called!"
self.logger("CopyBlocker.onFileOperation was called into.")

bar()

def didmount(self, aNotification):
foo()
print "Did Mount called"
self.logger("didmount: CopyBlocker was called into.")

def onNSWorkspaceDidMountNotification_(self,
aNotification):
"""A simple method which exists so this can be used for the
workspace mount notification during testing"""
print "*********"
self.logger("onNSWorkspaceDidMountNotification_: CopyBlocker
was called into.")


----------

The foo and bar functions do not exist; the intention is to create an
error should they get called.


I tried using the NSWorkspaceDidMountNotification and got it to call
into my didmount function. Trying with the
NSWorkspaceDidPerformFileOperationNotification, I have not seen any
indication that my method is called. I am heartened to see that
crankd complains if it can not find my module, but it doesn't seem to
mind if the function name is wrong. I added another dictionary key to
call a simple echo shell command, and it has never come up.

I notice that when crankd is started, it says:

DEBUG: FSEventStream started for 22 paths: /System/Library/Frameworks/
Python.framework/Versions/2.5/Extras/lib/python/PyObjC/CoreFoundation,
[and a large number of other python paths]

I would take it that it is not monitoring all paths and all filesystem
events.



Am I on the right track in believing that I can use crankd to prevent
files from being copied (or delete the copy right away should it
occur?) [Yes, I hate DRM, and this is just a little-bit big
brotherish.] What do I need to change to get some file system events
going through my code, and how do I make use of the event? (I found
the NSWorkspace Class Reference, but, beyond providing a link to the
notification center, it doesn't give me any clue of what sort of data
I would get back in ObjC, much less in Python.)

Thank you for your time.
Clinton Blackmore

[Chris Adams]

On Feb 18, 2009, at 12:54 AM, Clinton Blackmore wrote:
> I tried using the NSWorkspaceDidMountNotification and got it to call
> into my didmount function. Trying with the
> NSWorkspaceDidPerformFileOperationNotification, I have not seen any
> indication that my method is called.

I'll look into this tonight - but if you want some speculation before
I leave for work, I think you're right to suspect it's simply not
being called. You might have better results using the lower-level
FSEvents API - it's slightly different in that FSEvents will only tell
you when a directory has changed so you'd basically need to look for
changes to the desktop and scan for .apps. The good news about
FSEvents is that it's a low-level API and should catch things which
the higher level workspace notifications are missing.

The config file will be (IIRC) something like this:

<key>FSEvents</key>
<dict>
<key>/Users/foo/Desktop</key>
<dict>

<key>method</key>
<array>
<string>CopyBlocker</string>
<string>onFileOperation</string>
</array>
</dict>

</dict>

Chris

[Karl Kuehn]

On Feb 17, 2009, at 9:54 PM, Clinton Blackmore wrote:

> We have some problems when users copy a .app folder to their desktop
> when trying to put it on their dock; specifically, this prevents
> network users from logging in. Also, I'm aware of another system
> administrator who wants to prevents students from copying .apps to
> their USB drives.

Trying to catch this by watching filesystem events is the wrong
approach, you will always be chasing after things. The better
approach, at least for users who aren't going to resort to the command
line, is to prevent the Finder from copying the apps. There is an easy
trick to this: put a folder inside the .app bundles (next to
"Contents") that starts with "A" and don't give users read or execute
permissions on that folder (I would go with root:wheel:0000). When the
Finder enumerates the files it is going to copy it will run into that
and stop.

This is easy to circumvent by either copying things by opening
the .app bundle, or by working on the command line, but it does put up
a big enough barrier that most users won't be able to cross it.

--
Karl Kuehn
lar...@softhome.net

[Clinton Blackmore]

Now that is clever. I can't wait to try it.

Thank you.
Clinton

>                         lark...@softhome.net

[Karl Kuehn]

> Trying to catch this by watching filesystem events is the
> wrong
> approach, you will always be chasing after things. The better
> approach, at least for users who aren't going to resort to the command
> line, is to prevent the Finder from copying the apps. There is an easy
> trick to this: put a folder inside the .app bundles (next to
> "Contents") that starts with "A" and don't give users read or execute
> permissions on that folder (I would go with root:wheel:0000). When the
> Finder enumerates the files it is going to copy it will run into that
> and stop.

I did forget to mention that there is one dark side to doing this: it
breaks application signing. Apple has only started to use this, so
unless you are using MCX to restrict what applications a user can use
this will have no effect at the moment (this needs to be reviewed when
10.6 comes out). You can still work with it, you just have to make
sure that the application signing happens with your modification in
place. For a lab image this should be very doable.

--
Karl Kuehn
lar...@softhome.net

[Jeremy Reichman]

On 2/18/2009 12:54 AM, "Clinton Blackmore" <sabre.r...@gmail.com> wrote:

> We have some problems when users copy a .app folder to their desktop
> when trying to put it on their dock; specifically, this prevents
> network users from logging in. Also, I'm aware of another system
> administrator who wants to prevents students from copying .apps to
> their USB drives.

Is the problem you're trying to prevent specifically with the applications
in the Dock? Do you care if applications are copied elsewhere if they don't
prevent network users from logging in?

--
Jeremy

[Clinton Blackmore]

> Is the problem you're trying to prevent specifically with the applications
> in the Dock? Do you care if applications are copied elsewhere if they don't
> prevent network users from logging in?
>
> --
> Jeremy

My problem is this:

Teachers (I work for a school division) will occassionally instruct a
student to add an item to their dock. They show them how to go to the
Applications folder and drag the item to their dock. Occassionally a
student will misdrag and drop the item onto their Desktop. This moves
the application from /Applications to ~/Desktop (and then we get
helpdesk issues stating that the app is not installed on the computer,
for, so far as any other user can tell, it is not there.) Further, it
seems to prevent users from logging in -- I haven't looked into it in
detail but I think it affects users with mobile accounts, and that
synchronization never completes when there is a .app folder on the
desktop.

If a student were unable to copy applications to their desktop, my
issue would be resolved. [The other sysadmin I mentioned in my first
post, having a similar problem, wants to prevent students from copying
applications, and, presumably, installing them at home.]


I just tried the "A" file, owned by root with no read or write
access. It does work like a charm to prevent copying, but does not
prevent an application from being moved.

Taking the idea one step further, I set the ownership of an .app (just
the folder) to root:wheel and I am not able to move it or copy it
without authenticating! I think that this will solve my problem (and,
one might hope, not get in the way of application signing!) [It also
likely means that I will have to defer looking into crankd. Ah well.]

Cheers,
Clinton Blackmore

[Clinton Blackmore]

> I just tried the "A" file, owned by root with no read or write
> access.  It does work like a charm to prevent copying, but does not
> prevent an application from being moved.
>
> Taking the idea one step further, I set the ownership of an .app (just
> the folder) to root:wheel and I am not able to move it or copy it
> without authenticating!  I think that this will solve my problem (and,
> one might hope, not get in the way of application signing!)  [It also
> likely means that I will have to defer looking into crankd.  Ah well.]
>
> Cheers,
> Clinton Blackmore

Looks like I was mistaken. A standard user (I just created a local
account on a machine, but it should be equivalent to the non-admin
network users and mobile accounts) can still copy an application owned
by root:wheel. The "A" file trick works prefectly, as the user gets a
copy, instead of moving the app. [Which, in turn, makes me wonder if
users were dragging applications into the trash, or holding down
modifier keys, for us to get reports of the app not being installed on
the computer.]

Clinton

[Greg Neagle]

You've got serious configuration problems if students can _move_
applications out of the /Applications folder and onto their Desktop.
Students shouldn't have admin rights, and /Applications should not be
modifiable by anyone other than root and the admin group.

Ditto if students can _delete_ applications from the /Applications
folder.

I'd fix the basic permissions issues before I went scripting elaborate
workarounds.

-Greg

[Clinton Blackmore]

Thinking about it, you are very right indeed.

I feel embarrassed -- I had not tried to reproduce the issue I'd
mentioned, and see now that I got two issues confused. 1) Students
_copying_ files from /Applications onto their desktop and being unable
to log in, and 2) computers mysteriously not having software that
should've been deployed to them. These are minor problems here and
hence I've not had time to diagnose them. (I did jump at the
opportunity to learn about them when someone else had a vaguely
similar problem.)

Now, with my foot firmly in my mouth, would anyone pass the salt?

Cheers,
Clinton