0

I just discovered this fact tonight and I was rather floored by it. Isn't that a gaping security flaw? I realize that an external drive is less secure by virtue of the fact that someone could simply take the drive and move it to a different machine. In looking at this a bit different, it is possible to change OS X default behavior, but this change is actually noted on the internal (boot) drive, not the external drive. So anybody could still take the drive from one machine, which has this enabled, to another machine, which instead has the default for this drive, and totally bypass permissions. This is made worse by the fact that even if the drive is encrypted with FileVault, the problem still exists, because the password for the volume could be in the system keychain on the other device! (After all, another user might need to and have a legitimate right to access the files. But now the OS is letting the user make an end-run around that!) Oh, and apparently changing the default behavior isn't even protected, so a non-admin user can simply revert to the default and bypass permissions on the same machine!

In reading a bit further trying to get a grasp on what was going on here, I found an article which makes the claim "Drives that store data don’t use permissions and ownership. In fact, they shouldn’t use permissions." This struck me as rather strange! Why shouldn't drives that store data use permissions? What are permissions for if not to protect data from unauthorized users? Even if there is no malicious intent, there is still the very real concern of accidental damage.

I'm still trying to wrap my head around all this as it seems to go against all the principles of information security that I kind of took as a given. I am looking for an explanation either why what OS X is doing is okay, or if not, what can I do on OS X to mitigate this potential threat?

1 Answer 1

1

The problem is that ownership of a file is expressed by the UID of the owning user (and GID of the group).

The UID is usually generated locally when a user account is created. If you have accounts on different machines you will in many cases have different UIDs. (Unless you have a central user registry for all machines in question)

Thus, if you create a file on one machine, and attach the drive to another you have an account with the same name on, it would in many cases not "belong" to you.

Even if OS X would manage ownership based on user name instead of UID, how can it know that user "tom" on one machine is the same person as "tom" on another?

Admittedly, just ignoring ownership is taking the cowardly way out, but to do it right is not easy at all, especially if, as you say, other may have a legitimate right to access the data.

4
  • Thanks, that's a good explanation. This would still seem to be a problem with an internal drive too, it's just some degree harder to open up the box and get the drive out versus an external drive, right?
    – Michael
    Commented Nov 6, 2014 at 16:21
  • And I have to think that if you give your external drive the same degree of physical security as your machine (say having the external drive locked up so you could unplug it but not get the drive itself), Apple is still shooting you in the foot by not providing a foolproof way to secure the data from other users on the machine.
    – Michael
    Commented Nov 6, 2014 at 16:24
  • Additionally, if someone could plug the drive into another machine, they could plug it into a machine on which they have root (other than through encryption, if someone plugs your drive into their machine you cannot stop them from viewing what they want).
    – cpast
    Commented Nov 6, 2014 at 18:22
  • 1
    @Michael In fact, that's probably why Apple says that external drives shouldn't use permissions: unless an external drive is physically locked to one computer, someone can trivially bypass permissions by plugging it into their own laptop, so permissions generally cannot be relied on for security of an external drive. Having something that gives a false sense of security is worse than having nothing at all.
    – cpast
    Commented Nov 6, 2014 at 18:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .