Apple needs to work on their Encrypted Disk Images
I've been playing with the Encrypted Disk Image "feature" of Disk Copy. While it's interesting, I think it needs a lot of work.
First off, when you mount your encrypted image, the mount point is in /Volumes (as all mounts are). This means that unless you have file protections set up correction, ANY user also logged into your system can have access to your files. If your permissions are set correctly, they won't be able to read them, but that assumes a lot (mine weren't set correctly by default when I went to look, making the files world readable).
In addition, anyone with sudo/root access on your system (any admin) has access to all of your encrypted files, no matter what permissions you give them. This, in my opinion, is a serious security flaw.
Instead of this, it would be much more secure if the disk image and filesystem were left unencrypted. Instead, each file placed in this special filesystem would be encrypted and decrypted "on the fly". When mounting, the system could cache the user's passphrase, so this decryption and encryption is transparent. This would allow the admin/root user to copy, rename, or delete the files, but not read them.
Deletion on this type of filesystem could be "secure", with the 7x overwrite mandated by "secure standards".
The filenames could be encrypted with the user's passphrase as well, making them readable to the user alone, since a lot of information can be gleemed from said filename.
It would also be nice if the mount point could be specified to be somewhere other than the default /Volumes, for security reasons. Some standard "private" directory in your own home directory, for instance. For consistency, you could still put a symbolic link to it in /Volumes, but other non-admin users wouldn't be able to follow it.
Apple seems to still be thinking of OS X as a single-user system. However, with its Unix underpinnings, it is inherently a multi-user system.
(I've also submitted this to Apple's Feedback, but I thought I'd post it here for comment.)
First off, when you mount your encrypted image, the mount point is in /Volumes (as all mounts are). This means that unless you have file protections set up correction, ANY user also logged into your system can have access to your files. If your permissions are set correctly, they won't be able to read them, but that assumes a lot (mine weren't set correctly by default when I went to look, making the files world readable).
In addition, anyone with sudo/root access on your system (any admin) has access to all of your encrypted files, no matter what permissions you give them. This, in my opinion, is a serious security flaw.
Instead of this, it would be much more secure if the disk image and filesystem were left unencrypted. Instead, each file placed in this special filesystem would be encrypted and decrypted "on the fly". When mounting, the system could cache the user's passphrase, so this decryption and encryption is transparent. This would allow the admin/root user to copy, rename, or delete the files, but not read them.
Deletion on this type of filesystem could be "secure", with the 7x overwrite mandated by "secure standards".
The filenames could be encrypted with the user's passphrase as well, making them readable to the user alone, since a lot of information can be gleemed from said filename.
It would also be nice if the mount point could be specified to be somewhere other than the default /Volumes, for security reasons. Some standard "private" directory in your own home directory, for instance. For consistency, you could still put a symbolic link to it in /Volumes, but other non-admin users wouldn't be able to follow it.
Apple seems to still be thinking of OS X as a single-user system. However, with its Unix underpinnings, it is inherently a multi-user system.
(I've also submitted this to Apple's Feedback, but I thought I'd post it here for comment.)
Comments
Originally posted by Paul
you dont need to keep them mounted all the time... or am i missing a point
You do not, but the minute you do it is vulnerable. That's not very good security.
What if a hacker has gotten into your system? It's harder than on Windows, but Unix apps certainly do have flaws that are found now and then, such as sendmail. Said hacker could easily set up a script to continuously monitor /Volumes for new mounts, and as soon as one appears copy all files to an FTP site somewhere.
If they are giving me a feature for security, I want it to be truely secure! I'll grant you that it's much better than nothing (as in, if my PowerBook is stolen, my secure data will most likely be unobtainable). I just want more.
also i think protection like that is for insecure people...i've never worried about it and never have i been hacked or have informatino stolen
who can log into your system that u don't want to be able to see things...DON'T MAKE THEN AN ADMIN!
so i see ur point and for the VERY FEW it effects...unplug ur computer, u have a valid point but in general i say
Originally posted by John Whitney
In addition, anyone with sudo/root access on your system (any admin) has access to all of your encrypted files, no matter what permissions you give them.
This is how Unix works; root has access to everything.
Originally posted by John Whitney
Instead of this, it would be much more secure if the disk image and filesystem were left unencrypted. Instead, each file placed in this special filesystem would be encrypted and decrypted "on the fly". When mounting, the system could cache the user's passphrase, so this decryption and encryption is transparent. This would allow the admin/root user to copy, rename, or delete the files, but not read them.
Not really. root could su to your account and access the files. Or root could ptrace a process that's running as you and access the files.
To really solve this problem you'd have to remove root completely, which is very complex/expensive (see Trusted Solaris, Trusted IRIX, etc.)
if it's never been enabled, and has no password set, then you're correct and they'd be able to access everything.
of course, if you have someone on your machine who's root you've got bigger problems than them being able to access your mounted volumes.
Originally posted by wmf
This is how Unix works; root has access to everything.
Not really. root could su to your account and access the files. Or root could ptrace a process that's running as you and access the files.
To really solve this problem you'd have to remove root completely, which is very complex/expensive (see Trusted Solaris, Trusted IRIX, etc.)
Root has access to all files. That doesn't mean root has access to the contents. For example, root cannot decrypt my password... the best it can do is overwrite the old one with a new one. The same applies here... root should not be able to read my encrypted files.
And no, using su to become a user would not necessarily instantly grant access to the files. The "cached" passphrase could be attached to a particular shell (login), or the passphrase could not be cached at all and be required for each access by an application.
root could potentially snoop through the kernel's memory (/dev/mem and /dev/kmem seem to exist), but that wouldn't be a simple task. ptrace is also an option, but again this wouldn't be a simple task (not to mention it would be noticeable).
In fact, if Apple wanted to get really fancy, they could put in a mechanism to prevent accesses to pages in memory except for the user that currently owns it, or perhaps the application that owns it (and the kernel, of course).
Originally posted by alcimedes
of course, your best bet would be to set up the root account with a hardcore password, then it doesn't matter if you're an admin, you can't su to root w/o that password.
if it's never been enabled, and has no password set, then you're correct and they'd be able to access everything.
of course, if you have someone on your machine who's root you've got bigger problems than them being able to access your mounted volumes.
Assuming you've disabled sudo access to Admin accounts as well, then your first couple of paragraphs are correct. However, I disagree with the last paragraph. If someone has root access on my machine, I can always wipe the harddrive, reinstall from scratch with all new passwords, and start over clean.
If an infiltrator accesses my "encrypted" files and gains access to all of my credit card account numbers, dates, social security numbers, and other private information, there's no WAY I can undo that. That is a big problem.
Well, get to writing a VFS plugin for PGP.
Originally posted by Kickaha
So basically what you want is per-file, per-access on the fly encryption/decryption, instead of an encrypted disk image.
Well, get to writing a VFS plugin for PGP.
Ack! No fair asking me to actually do something instead of whining!
Seriously, I wouldn't mind but we'll have to see if I find the time and inclination (other projects and family take precedence, right now). I've never done filesystem work, but it might be possible to just take an existing implementation of a filesystem (UFS?) and just add encryption on top of it. Governmental regulation/export restrictions are a pain in the ass, however.
Originally posted by John Whitney
Ack! No fair asking me to actually do something instead of whining!
Bitch, whine, moan.
I've never done filesystem work, but it might be possible to just take an existing implementation of a filesystem (UFS?) and just add encryption on top of it.
The Virtual File System keeps you from having to do that, period. That's what it's *for*. Instead of doing the other-OS approach of having to have all sorts of filesystem formats running around all slightly compatible with each other, VFS lets you have plugins that perform actions on a data stream. Think of it this way - your encryption plugin would sit between the OS access to the data, and the actual filesystem, whether it's HFS+, UFS, or what have you. Any calls from the OS to read data go through to the filesystem, where the encrypted file is read, passed back up the chain to your plugin where it is decrypted, then passed on to the OS. The OS never even knows it's encrypted before it gets it. The file system never knows that it's dealing with encrypted data, it just reads off the file and hands it back. Writing data to a file has the OS send the data downstream, where it is encrypted by your plugin, and handed off to the filesystem.
The data is *never* unencrypted on disk, only in RAM. (Well, except for swap space files, which you may want to not have encrypted for performance, or keep encrypted for security.
This is how journaling was added to HFS+. It's a plugin.
Note that at no point do you have to do filesystem work.
Originally posted by John Whitney
For example, root cannot decrypt my password... the best it can do is overwrite the old one with a new one.
root can do that? for any encrypted DMG? how?!
Originally posted by Paul
root can do that? for any encrypted DMG? how?!
Paul,
I'm not sure how this post relates to the quote it contained. The "root can't decrypt passwords, just change them" isn't really related to DMGs, just powers and constraints that root has.
As related to encrpyted DMGs, if you have them mounted so you can access them, then the root user also has access to all of your "encrpyted" data (which I see as a huge security flaw).
John
Originally posted by John Whitney
Paul,
I'm not sure how this post relates to the quote it contained. The "root can't decrypt passwords, just change them" isn't really related to DMGs, just powers and constraints that root has.
ah, so just your system password, not the password of DMG's on the computer...
As related to encrpyted DMGs, if you have them mounted so you can access them, then the root user also has access to all of your "encrpyted" data (which I see as a huge security flaw).
John
gotcha...
I was just thinking if root could replace the p/ws of encrypted dmgs that would be a huge security flaw, because not only would they be able to see the data (they know the new password) but you would not be able to see the data anymore (as you do not know the new password)
as for your problem, who has access to your machine that you would be worried about hackers... and if you system has been hacked to that point already, what is stopping them from seeing that unencrypted data wherever it shows up on the HD instead of the Volumes folder?
The only real way to close this hole is to only allow unencrypted data in Ram (as Kickaha suggested...) and all data in the HD be encrypted (as per your discretion of course...)
Originally posted by Paul
as for your problem, who has access to your machine that you would be worried about hackers... and if you system has been hacked to that point already, what is stopping them from seeing that unencrypted data wherever it shows up on the HD instead of the Volumes folder?
The only real way to close this hole is to only allow unencrypted data in Ram (as Kickaha suggested...) and all data in the HD be encrypted (as per your discretion of course...)
The whole internet has access to my machine, as it is on an always-on cable connection. In general, it's secure. However, security bugs in software come up all the time, and open source can be just as bad as closed (in some cases easier, as you can search the source code for flaws).
My whole point was the files on disk should never be available unencrypted, either in /Volumes or anywhere else, as they currently are.
I'm not sure what you mean by "shows up on the HD". That implies all data has to first be saved unencrypted to the standard HD, then moved to the encrypted volume, which isn't the case. The original save can be to the encrypted disk image.
I want exactly what Kickaha was suggesting, a VFS plug-in (or some other method) that allows me to have all files stored on this filesystem to be encrypted. This way, unless root is snooping through RAM, they (and any other user) can't read the files, mounted or not.
Originally posted by ThunderPoit
you people seem to be talking about root like its some wide open back door or somthing. How many people use your computer or can attempt to access it over the network??? or are your .dmgs on a server that you are afraid root might try to access?? root, by default, is not active on any os x install, you need to activate it yourself. it the files are on a remote server, you simply have to trust root- who is by the way, the admin of the server/network that your files are on, not some malicious punk hacker- with your stuff, theyre payed very generously for this simple task.
While the root account is not active, root access is through the use of sudo from any Admin-enabled account. "sudo bash" gives you a root prompt, without ever "enabling" root.
I should not have to trust *anyone* but myself for confidential information. That's the whole point of encryption. Would you mind if root were reading your encrypted email to a friend/lover?
As for "or can attempt to access it over the network", that would be the entire internet. My PowerBook is connected to the internet 24/7. As I have said before, while it is generally secure, you never know when a software exploit could blow it wide open (see various Windows worms, and security fixes to various Unix software). ANY computer connected to the internet is a potential target for hacking. This is why you don't see high-security government/military computers connected to the internet.
Take a look at some big corporations that have had breakins to their machines (and these are machines theoretically set up by experts) and lost thousands of credit card numbers. Granted, I'm not the same sort of target, but I wanted to point out that computers aren't perfectly secure.
That's why I want to make damned sure my financial files (and other private information) are secure from ANYONE without the appropriate passphrase.
John
Originally posted by ThunderPoit
well, as stated before, if the files are encrypted, its a non-issue as only you will know the password. and if root is disabled, dont give out the l/p for the admin acct. security is alot simpler than you think it is...
If that's what you want to believe, feel free. I hope your box is never hacked, and I hope you or some other user of your computer never download a trojan program or virus that gives access to it to outside influences.
As for me, I'll take more security, so that I am protected even if the worst happens. I don't really understand why you'd object to having a more secure system.
I work with Unix professionally and on a daily basis, and I know that security is a lot more complex than you are making it appear.
John