Lock Down JAMF System Files
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Posted on 05-22-2016 09:24 PM
Hey All,
I'm looking for a way to completely lock down the System files - Specifically LaunchDaemons but will settle for a blanket fix.
Basically we have students who are deleting the contents of their /Library/LaunchDaemons folder to remove the Mobile Filter Agent and Youtube for Schools policy. Instead of deleting what they need to though, they delete everything and it messes with any programs you have relying on a LaunchDaemon.
So far I have:
Hidden the contents of /Library using chflags
Turned off the ability to search for a folder in finder using 'Go To'
Taken admin access away from kids who are found with no LaunchDaemons, or at least without the important ones (to us).
Any more suggestions? I am also thinking about what we can do at the beginning of future images to disable access to these folders.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Posted on 05-22-2016 09:49 PM
How are you detecting these folders are being cleared?
What grade are we dealing with here? And are these lab computers? If so, why do the students even have admin access on them? Are these part of a 1 to 1 program? If so, then that may get a little tricker, but I think ultimately falls on disciplining them and getting administration involved. Depending on how you are detecting those folders are being cleared then I'm guessing that there is still an MDM connection to the computer which probably means you can 'lock' the computer forcing the student to have to bring it in. These are just ideas though. Maybe others in education will have better advice.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Posted on 05-22-2016 09:55 PM
They are 1 to 1 devices from grades 6 to 12 - we are detecting them based on the fact that they are no longer checking in to the JSS so there is nothing we can do as far as pushing anything out. The policies I mentioned are currently being pushed out as preventative, but there are about 145 students we have determined have not been checking in since the beginning of May.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Posted on 05-23-2016 05:16 AM
If the students are local admins, then that's the biggest issue. There will almost always be some way of getting around restrictions as an admin, unless it's part of Apple's MDM spec (which as you've been able to see, this is not).
You could try restricting Terminal access; that would be a way to remove those files regardless of Finder restrictions.
You may also want to look into @rtrouton's great CasperCheck script. If your users are given the permission to remove LaunchDaemons then they could certainly remove CasperCheck's, but perhaps naming its plist file something misleading would prevent at least some users from removing the file indiscriminately, and could help restore the connection to the JSS should the other steps be ineffective.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Posted on 05-23-2016 09:50 AM
Seconding removing local admin rights and CasperCheck.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Posted on 05-23-2016 10:42 AM
There is no perfect solution here. As others have mentioned, with end users having admin rights on a box, all bets are off regarding keeping these machines under management. If its possible to remove admin rights, and then open up some of the items they may still need to be able to do such as get at some System Preferences that normally require an admin password to unlock or such, that would help a lot. Other things can be put into Self Service that might be hard or impossible to allow them to do as non admins.
Lastly, I doubt I would really do this myself, since it could cause some very strange issues, especially with future Casper upgrades pushed down to your boxes, but just as an extra option, you could also set the immutable flag on the /Library/LaunchDaemons/ directory. This would prevent even a sudo rm command from working on removing it without first removing the immutable flag.
sudo chflags schg /Library/LaunchDaemons/
Of course the big problem with the above is that going forward, any installers that might need to drop something there or make modifications to items in it would fail. At least until that flag is removed from the directory. Maybe the better option would be to set that immutable flag on just the LaunchDaemon plists you care about and not the whole folder. Of course, test, test and test some more before relying on something like this. I'm afraid you could run into some problems with that approach as I mentioned.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Posted on 05-27-2016 05:17 AM
I've got to agree here. High school students will ALWAYS 'play' with stuff if they are admins. I'm not sure how you can manage this without risking the normal operation of the OS. Are there specific reasons why your students have administrative access? I've always found simpler ways to enable features and functions that might have otherwise required Administrative access for.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Posted on 04-03-2019 03:25 AM
You can't resolve a personnel issue with an IT policy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Posted on 04-03-2019 04:30 AM
If you want a big stick, and are allowed to use it - Kill the login process if they bin the files. They will have to come back to you to get it fixed.
You can create a script to run at boot as a LaunchDaemon, you can then get the script to do whatever you want if the contents of any folder changes. You could store copies of the files in a safe location, and then copy them back and re-launch them. The script will work at this point, because the process will still be running. They have to use launchctl unload to stop the process, or reboot the Mac. My guess is they are rebooting. To save time you can create a onetime Daemon, that does the copies for you at boot, this will make the process very quick, it then bins itself when completed.