Encrypted disk image opens without password

Question

Level 1

43 points

Encrypted disk image opens without password

Sometimes when I switch users, I find that an encrypted disk image has mounted, and its contents are available. This happens only when I go from the main user (with standard privileges) to a different standard user. Neither user has the encrypted disk password stored in Keychain Access. I can’t figure out how to reproduce this problem, but it occurs about 5-10% of the times I switch to the second user. (Minor rant 1: I have never heard of an encrypted disk image doing this. It shouldn't be possible.) The encrypted disk image is very large (>100 GB), and I will have to make a new one because even if the problem is identified, I'll never trust this one.

Privilege info that may not be relevant:

Get Info shows that three standard users (one of which is me) have "Custom" privileges. I set-up the disk image so the three users would have "read and write" privileges, and that's what TinkerTool System shows. Get Info also shows that user groups firebird, _unknown, and everyone have "read and write" privileges. I did not grant any privileges to group everyone, and groups firebird and _unknown weren't on the initial list of privileges. I fixed privileges, except I cannot delete the firebird group. (Minor rant 2: Apple totally mucked up privileges. It did not need to adopt the entire set of UNIX privileges. Firebird shouldn't exist as a group. The OS should check the privileges of installed apps and ask the user what to do if the app has atypical permissions.) Privileges shouldn’t affect encrypted disk password security, but who knows what's contributing to this security nightmare.

Mac Pro (Early 2009), Mac OS X (10.6.8)

Posted on Nov 4, 2016 9:03 PM

Reply

Answer 1

a brody

Level 10

85,314 points

Nov 5, 2016 7:29 PM in response to iTBotB

Well it sounds to me as though some software installation messed up the privileges. This can happen with any administrative software install. This was a really bad problem under Mac OS X versions with Classic operating systems, but could still happen all the way up to Mac OS X 10.10.5. Apple included in each Mac OS X version starting with 10.1.5 a Disk Permissions repair facility which could be run from the boot system as an administrator. Go to Applications -> Utilities -> Disk Utility -> First Aid. This can usually fix most permissions issues on your system.

I would attempt running it with all other applications closed and the disk image unmounted.

If that does not solve problems, Make sure you are running the latest security updates for 10.6.8:

Combo v1.1 (7/25/2011), 10.6.8 2013 Security Update 004, 2013-005 Java update

In that sequence.

If it still doesn't work, it likely will not be repaired anytime soon, as Apple has not made a security update for Snow Leopard since 2013.

Before upgrading to any newer system, read this tip:

http://discussions.apple.com/docs/DOC-6271

Reply

Answer 2

Drew Reece

Level 6

10,684 points

Nov 5, 2016 8:16 PM in response to iTBotB

Repair permissions doesn't touch disk images or mounted volumes contained in disk images.

Repair permissions reads the package receipts & applies the permissions from them. I doubt it will alter anything in this situation aside from fixing any apps or supporting files that may be setup incorrectly.

As a test I made a 40MB dmg with encryption on 10.9 (password not saved).

User A mounted it.

I switched to User B.

User B could not view the contents (insufficient privileges in dialog) but the disk was still mounted.

User B is an admin so it had the ability to unlock & alter permissions - perhaps this is the issue? Have you modified the permissions as an admin on this mounted volume at any point?

Unmounting & remounting maintained the permissions that the admin set.

Personally I would test with new disk images. It is normal for OS X to keep volumes mounted when fast user switching. Disable FUS if you want to remove the potential for harm via this problem. Also test if the dmg is unmounted on logout. I remember there used to be a 'defaults write' command to set that behaviour as it used to cause havoc with network based user home folders.

FYI: 'Custom privileges' means the item is using ACL's and you may need to use the Terminal to verify or edit them. I suspect that may be the issue here. ACL's were added around 10.4 if I recall correctly before that it was only the 'unix model' (owner, group and everyone).

There are some tips around on managing ACL's…

ACL Tips

The firebird user seems like a user from the app, have you saved firebird data to the volume?

Look at the Terminal output for…

ls -ale /Volumes/test-dmg/

To see ACLs

I'm not sure how much is unexpected here - obviously the dmg should never mount if the password is not saved in keychain but the permissions may simply be misconfigured permissions?

Reply

Answer 3

iTBotB Author

Level 1

43 points

Nov 5, 2016 9:39 PM in response to Drew Reece

In my situation, all users were standard.

Permissions should not affect whether an encrypted disk image opens without a password. I've used encrypted disk images since they were first available on the Mac. I've never seen an encrypted disk image that opened without a password for any reason. I read lots of Mac info, and I've never read about this. But, I do think it's a permission issue, which scares me. I know the permissions were correct when I created the disk image because I always check. The open without a password problem did not begin until at least a month after creating the encrypted disk image. My assumption is that whatever altered the permissions also damaged the security of the disk image.

Since I fixed the permissions on the encrypted disk, I’ve switched to the second user more than a dozen times without a problem. I'll keep testing to see if the permission fix solved the problem. I’ll also make a new encrypted disk, but I’ll still keep testing the problem disk image.

I've had terrible problems with permissions on 10.6, which is why I always check new disk images. OS X 10.6 is not happy when you give one user permission to open the folders and files (including the Library folder) of another user. I had done this with 10.5 without problems. When I installed 10.6 over 10.5.8, the permissions nightmare began. I've reset permissions to the individual folder level, and sometimes the file level, but they spontaneously get screwed-up. I have no idea why. I may have to do a clean install of 10.6 (which I’ve done twice) but this time manually copy files to my new boot volume after resetting permissions on every folder and its contents. That’s probably a two-day job. I had to do that after I installed 10.11 over 10.6.8.

Reply

Answer 4

Drew Reece

Level 6

10,684 points

Nov 5, 2016 11:05 PM in response to iTBotB

Your summary of the permissions & the mounting is correct but I can't believe permissions would alter the encryption state of a disk image - it just doesn't work like that.

I suppose you could have a certificate set up to unlock the dmg, however that seems unlikely - dmgs support multiple ways to unlock them. Again that would be managed in Keychain Access so be sure to hunt of the disk image name in Keychain Access - it is the only way I can explain an encrypted volume mounting without a password dialog.

You can also try mounting the dmg on another Mac (or on another OS install) - if that requires the password you know it is your Mac. Try mounting from a brand new user account to rule out the existing user keychains.

Eject the image in Disk Utility & select it in the sidebar (drag to Disk Utility if it isn't already there). Get info via the ℹ or the File menu.

Does that say it is encrypted?

Also Terminal can tell you via the hdiutil command…

hdiutil isencrypted Desktop/test.dmg

encrypted: YES

blocksize: 512

uuid: 5752F3EA-C54C-4270-84AF-33882A463694

private-key-count: 0

passphrase-count: 1

max-key-count: 1

version: 2

iTBotB wrote:

I've had terrible problems with permissions on 10.6, which is why I always check new disk images. OS X 10.6 is not happy when you give one user permission to open the folders and files (including the Library folder) of another user. I had done this with 10.5 without problems. When I installed 10.6 over 10.5.8, the permissions nightmare began. I've reset permissions to the individual folder level, and sometimes the file level, but they spontaneously get screwed-up. I have no idea why. I may have to do a clean install of 10.6 (which I’ve done twice) but this time manually copy files to my new boot volume after resetting permissions on every folder and its contents. That’s probably a two-day job. I had to do that after I installed 10.11 over 10.6.8.

I'm afraid your setup seems wrong to me, you should not need user A to be able to access the Library of User B & vice versa. You are getting into unknown territory when you make custom setups like this.

OS X has a tool to reset user permissions but you have to boot from the install DVD (or recovery system on later OS's). Basically enter Terminal from the top menu of the install screen, then type

resetpassword

Hit return, a GUI app will open, you can select the user and at the bottom of the window & apply the option to reset user permissions.

Use that if you want to restore default home folder permissions, I don't really understand why each user needs to access the others data like this?

Reply

Answer 5

iTBotB Author

Level 1

43 points

Nov 6, 2016 6:27 AM in response to Drew Reece

I'm afraid your setup seems wrong to me, you should not need user A to be able to access the Library of User B & vice versa. You are getting into unknown territory when you make custom setups like this.

Since all users are me, my setup does make sense. My second user has almost no documents and as few permissions, Application Support, and other Library files as possible. I use if for downloading and testing "iffy" applications and utilities, primarily freeware from individuals. When I'm logged on as user B, I sometimes need to access files from user A. I do not wish to log off, copy the needed files to a shared folder, and log on as user B. Giving user B access to user A files is a perfectly legit permissions setup under UNIX. As I said, my atypical permissions worked fine under 10.5, but they have not worked since.

Try mounting from a brand new user account to rule out the existing user keychains.

Eject the image in Disk Utility & select it in the sidebar (drag to Disk Utility if it isn't already there). Get info via the ℹ or the File menu.

Does that say it is encrypted?

If I've got an existing keychain, it is invisible and comes into use only one in twenty times or so. I know the disk image is encrypted because it needs a password to open approximately nineteen times out of twenty.

My guess after more playing around and reading the comments above is that the encrypted disk image had to be flawed when I made it. Some unknown combination of circumstances results in the flawed disk image opening without password when user B logs in. Note that it isn't just waiting to be opened by me and doesn’t ask for a password. It's already open when the login is complete. It's weird that an unmounted volume will mount without a command and it's infinitely weirder that it does so when a password should be required.

I'm going to close this thread because I doubt that the cause can be determined, and the "fix" is simply to make a new disk image.

Reply

Answer 6

Drew Reece

Level 6

10,684 points

Nov 6, 2016 6:45 AM in response to iTBotB

All users have a Keychain by default. Please open Keychain Access and take a look in the login keychain for the disk image name.

If you want to resolve the issue do not mark it solved otherwise others will not offer help.

Reply

Answer 7

iTBotB Author

Level 1

43 points

Nov 6, 2016 7:23 AM in response to Drew Reece

All users have a Keychain by default. Please open Keychain Access and take a look in the login keychain for the disk image name.

If you choose not to save the password in Keychain, then there is no file. I do not store keychain passwords for my encrypted disks, because Keychain is too easy to crack.

If you want to resolve the issue do not mark it solved otherwise others will not offer help.

I doubt that anyone will know the cause of this. Even if someone thinks he knows the cause, I don’t think I can confirm it without extensive testing, which I am not willing to do. Thus, as far as I'm concerned, the issue is over and I want no more replies.

Reply

Answer 8

Drew Reece

Level 6

10,684 points

Nov 6, 2016 7:36 AM in response to Drew Reece

Also another point just occurred to me, disk images have multiple states…

attached & mounted

Attached is when the image has a device file (or multiple) - this is after decryption.

Mounted is when one of the device files is mounted.

It is possible to eject a disk image volume but not detach it. That means the store is still decrypted & the volumes can be remounted.

I have absolultelty no idea if this is the case for you - but it is another valid reason that could explain what you see. You can remount under certain conditions without a password.

You can either look at this info via Terminal & the hdiutil command or look at Disk Utility.

Here is some screenshots from Disk Utility sidebar for an encrypted image in it's various states…

'man hdiutil' has more info too in the manual…

https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPag es/man1/hdiutil.1.html

Reply

Answer 9

Drew Reece

Level 6

10,684 points

Nov 6, 2016 7:37 AM in response to iTBotB

iTBotB wrote:

Thus, as far as I'm concerned, the issue is over and I want no more replies.

Oh right, I didn't see that before I just posted.

Good luck with it.

Reply