Posted on 03-06-2013 08:39 AM
*Preventing....D'oh
Title says it all. Mostly a 10.7/10.8 deployment.
Best
Posted on 03-06-2013 08:59 AM
you could remove the security preference pane, but they'd still be able to use the corestorage commands from the command line. I'd love to hear anyone's ideas, too.
Posted on 03-06-2013 09:09 AM
Lock the 'Security & Privacy' Preference Pane with MCX or Profiles. Its not a perfect solution, since there are actually ways for local admins to bypass the lock out settings in Preference Panes, and you can also decrypt a drive from the command line as well, but it should stop most cases since generally most people would try to do it from the GUI.
You could also build Smart Groups to immediately detect any Macs that have been decrypted or are the process of decryption and take some appropriate action, like notifying the user, or the user's supervisor.
Lastly, this is case where a good AUP would be helpful.
Edit: I apparently took a long time writing up my comment since nkalister beat me by about 10 minutes :
Posted on 03-06-2013 09:12 AM
Hate to tell you, but they don't need admin to decrypt. They can boot to the Recovery partition and do it. They're allowed to unlock it so they're allowed to decrypt it.
Posted on 03-06-2013 09:15 AM
True, then set up a Firmware Password they don't know so they can't boot to Recovery HD. Its an ugly solution, but we do it, much to the chagrin of our users. But you're correct, once you can boot to Recovery HD, all bets are off regardless of their rights on the normally booted system.
Posted on 03-06-2013 09:47 AM
Please do forgive the unsolicited preaching:
Fences, not walls.
Monitoring tells you when people jump your fence. Then it becomes (more of) HR's responsibility.
Do you foresee issues by removing recovery options when FDE is enabled? Then enforce with policies, not technology - it could avoid a confrontation with a misguided user(that could also be your CEO/boss/Dean.)
Allister
Posted on 03-06-2013 10:00 AM
^This.
I've had a saying for this for years and it holds true in 99% of cases. "There are no technical solutions for social problems."
Posted on 03-06-2013 10:18 AM
You don't even need to be booted to Recovery HD to decrypt your boot drive. Assuming that your account is authorized to log in at the FileVault 2 login screen, you can decrypt like this:
diskutil cs revert UUID_here -stdinpassphrase
Your boot drive will begin decrypting.
Note: You do not need admin rights to run this command. The only thing FileVault 2 will care about is if you're an authorized user. If you are, it'll let you decrypt.
Posted on 03-06-2013 10:55 AM
I would have to agree the best thing here is a good, strong AUP that is actually backed by senior staff and HR. Its true there is no real technical solution to prevent users from bypassing controls.
Posted on 03-06-2013 11:03 AM
Manage through people and not technology.
If they unencrypt your drive, you'll know about it when you run reports. If that happens there should be a HR/users manager process in place to deal with it.
Posted on 03-06-2013 11:57 AM
Here's another glitch in this setup.
If I enable FV2 and give permission to unlock to UserA buit not UserB, if UserA boots up, and logs in, then the disk is unlocked. Say then UserB goes to the login window, UserB (admin) can login and then disable FV2, even though UserB is not "enabled". Seems Apple could make it a little more difficult to not undo FV2 even though as was stated, it's really a "people problem". As we all know, we don't always get mgmt and/or HR support in these matters - "just do it" or "make it work" is sometimes the order of the day.
I think with a little more tweaking, Apple could make FV2 more secure, while more flexible too. Another 2¢
Many of the suggestions here are going to be good enough unless your user base is smarter than average :)
Posted on 03-06-2013 12:23 PM
It's the nature of the beast, unfortunately. You can go with another disk encryption solution but you're going to A) Pay extra for it B) May not have it managed with Casper C) Will run into firmware update issues D) I'm sure lots of other unforeseen issues.
There's only a certain extent that you can manage the technology. If people abuse it, they should lose their right to it and don't be afraid to say, "I told you so."
Posted on 03-06-2013 01:10 PM
Hi Everyone,
I recently helped a customer report on FV2 status on 10.8 machines. I did it via extension attribute. Basically you run this command:
bash-3.2# fdesetup status
FileVault is Off.
Then take the output and echo it in some <result> tags. Then build a smart group of "non-compliant," machines and be able to scope out policy, and report it. Like many things, there are many ways to address this issue. When working with my customer we decided reporting was the first step. After the smart groups got populated, action could be taken after the fact.
In this case they were using FileVault 2, and 10.8 so we used the built in tools. I cannot say this is exactly how it would work with other encryption products as I haven't done extensive work with them.
I hope this helps,
Tom
Posted on 03-08-2013 07:22 PM
Rich Trouton has a very good EA for filevault which, iirc, works on Lion and ML. Can't find it from my tablet though.
Posted on 03-09-2013 10:19 AM
If you've got an EA to show decrypted drives why not just set up a smart group and force them to encrypt again. I'm sure they would get bored of repeatedly decrypting their machine faster than Casper would get bored of re-encrypting it!
Posted on 03-11-2013 08:30 AM
I get the "let people manage themselves" idea.
But..
If I want to make it so a user can not decrypt his or her machine then I should be able to.
Just like any other 3rd party encryption solution. Apple needs to give us the ability to do this. I am not holding my breath waiting though.
Posted on 03-11-2013 08:54 AM
Physical access will trump any control.
As long as users have physical access, they will likely find ways to get around your controls. While I agree that Apple may need an "enterprise/institution" solution to centralize the capability of decryption, it is likely some thing we'll have to handle via policy and reporting.