[Casper] Prohibit copying from /Applications
John DeTroye
detroye1 at apple.com
Wed Feb 18 11:09:44 PST 2009
Just to make sure there isn't -yet more- confusion, here's the skinny
on application management using MCX (from my Tips doc - p. 32):
d. Applications
Management and control over applications has improved radically since
Tiger. Whereas before, a user could drag an application into their
home directory and alter it to bypass restrictions, and where schools
had to totally disable Dashboard to stop users from running unapproved
Widgets, Leopard MCX has much better control.
1. Applications themselves
There are two different settings for application management, one is
the ability to digitally sign applications to keep them from becoming
altered. While this is a great setting, it does not provide
application restrictions. The setting is missing the ability to set
“don’t allow anything but signed apps to run” or something to that
effect. This renders the signing ineffective as a control mechanism.
What works best for application management is path or folder
restriction. You can set the locations where applications are allowed
to run, and locations that are forbidden. <snip>
(Picture here of the allowed being /Applications and /Library,
disallowed being things like ~/)
The idea here is that the default Applications folder is safe, and
the /Library folder often contains sub-launched apps needed by
mainstream ones. The user does not have permission to mess with either
of these folders. You could further restrict /Library by designating
just the Application Support folder. I found that a few sys admin
apps, such as Sassafras’ K2 tools need to run as a user task from /
Library itself. Note that the user’s homedir is not allowed - so even
if someone downloads an application to their home, they can’t launch
it. You could also deny use of Installer. While the dialog box says
‘Folders’, what it really means is the path. This means that you can
add the path directly to an application as denied. The rules work like
a firewall; so denies always win, and you can allow an app inside a
denied folder - except - if you add the application to the
‘Applications’ pane, it can be launched anywhere, including from
inside the user’s home directory.
johnd
--
John DeTroye Email: johnd at apple.com
Sr. Consulting Engineer Systems Management Specialist
Apple - Education iChat: johnd at mac.com
Systems Management Guide - http://www.apple.com/education/go/sysmgmt/
Tips and Tricks Docs - http://web.me.com/johnd/
--
On Feb 18, 2009, at 11:03 AM, Jeff Strauss wrote:
> No, what I’m doing now is just adding a folder inside the Office
> 2008 app folder. I am using MCX to restrict apps, so I’ll see how it
> goes.
>
>
> On 2/18/09 9:57 AM, "Clinton Blackmore" <clinton.blackmore at westwind.ab.ca
> > wrote:
>
> Funny you should post that. The same user posted the same solution
> to my question on the MacNN forums yesterday. I’m testing it out
> today.
>
> Fascinating. Please let us know how well it works. (Did you write
> a script that can be deployed by Casper to do it?)
>
>
> The author who suggested the technique just added that:
>
> 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
>
>
> On 18-Feb-09, at 10:33 AM, Jeff Strauss wrote:
>
> Funny you should post that. The same user posted the same solution
> to my question on the MacNN forums yesterday. I’m testing it out
> today.
>
>
> On 2/18/09 9:28 AM, "Clinton Blackmore" <clinton.blackmore at westwind.ab.ca
> > wrote:
>
>
> I started seeing if I could figure out how to do this with crankd
> (which, while it has potential, is still in its infancy and not well
> documented), and, after getting something together that didn't
> work, I
> posted to the pymacadmin site. The thread is here: http://groups.google.com/group/pymacadmin/browse_thread/thread/2c077fcd1ed7361f
>
> The last response I got is very worthwhile, so I am sharing it here:
>
>
> 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
> lark... at softhome.net
>
>
> On 14-Feb-09, at 3:16 PM, Jeff Strauss wrote:
>
> > Thanks for that. I'm going to start work on it after the weekend.
> > Expect email asking for help :)
> >
> > Sent from my iPhone
> >
> > On Feb 14, 2009, at 2:17 PM, "clinton.blackmore" <clinton.blackmore at westwind.ab.ca
> >> wrote:
> >
> >> Darn. Here I'd always hoped that some funky set of ACLs could
> >> prevent the problem. We have a problem where students move
> >> applications onto their desktops when trying to put it on their
> Dock
> >> (and then we get complains that the app is not installed, or that
> >> users (inexplicably) can not log into network accounts with a .app
> >> on the desktop.)
> >>
> >> If you are serious about writing a launchd item, and especially if
> >> your running all Leopard, there is a python application called
> >> crankd that can install hooks into system events (like filesystem
> >> activity, network transitions, and such) and call your code when
> it
> >> happens. I don't know a lot about it, but http://code.google.com/p/pymacadmin/
> >> is a place to start looking. I think it might be easier to work
> >> with than launchd.
> >>
> >> If you do come up with something, I'd appreciate it if you'd
> share.
> >>
> >> Cheers,
> >> Clinton Blackmore
> >>
> >>
> >> _______________________________________________
> >> Casper mailing list
> >> Casper at list.jamfsoftware.com
> >> http://list.jamfsoftware.com/mailman/listinfo/casper
>
>
> This email has been scanned by Barracuda Network's Anti-Virus and
> Spam Firewall.
>
>
>
> Jeffrey A. Strauss
> Department of Educational Technology
> Systems Administrator
> Loyola High School of Los Angeles
> 1901 Venice Blvd.
> Los Angeles, Ca 90006
> (213) 381-5121 x265
>
> Please consider the environment before printing this e-mail.
>
>
>
>
>
>
> Jeffrey A. Strauss
> Department of Educational Technology
> Systems Administrator
> Loyola High School of Los Angeles
> 1901 Venice Blvd.
> Los Angeles, Ca 90006
> (213) 381-5121 x265
>
> Please consider the environment before printing this e-mail.
>
> _______________________________________________
> Casper mailing list
> Casper at list.jamfsoftware.com
> http://list.jamfsoftware.com/mailman/listinfo/casper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.jamfsoftware.com/pipermail/casper/attachments/20090218/771b32ea/attachment.html
More information about the Casper
mailing list