7 ms·

"But because of a subtlety of Unix systems (of which macOS is one), when an existing file is moved from another location to the root directory, it retains the s

"But because of a subtlety of Unix systems (of which macOS is one), when an existing file is moved from another location to the root directory, it retains the same read-write permissions it previously had." And ownership. (The sentence before that suggests "root directory" here means "directory owned by root".) The permissions on the directory apply only to the file's directory entry, not the file itself. This isn't a "subtlety", it's how it works, and no-one who doesn't understand this should be writing macOS installers. The correct approach is to open the file for read and copy its bytes into your private area. Only then check the cryptographic signature. Just renaming into your private directory isn't enough, even if that directory has no read or execute access to other users, because the attacker could have opened the file for write access before you did the rename.

pleb_nz 4y ago
I might be misunderstanding what you are saying, but it sounds like a lot of reliance on people knowing and wanting to do the right thing?
- jacquesm 4y ago
  Most of unix is like that though.
  - hungryforcodes 4y ago
    This cannot be said enough.
- zbird 4y ago
  I'm not sure what you're suggesting. Would you go to a doctor who doesn't know or want to do the right thing?
  - stevehawk 4y ago
    No, we go to facebook sir.
  - whatshisface 4y ago
    Yes, and the way you'd end up doing that is by not having doctor telepathy.
  - pleb_nz 4y ago
    So how do you prevent bad actors from abusing this and/or train every developer on the planet to ensure they do they follow the right processes. Sounds like its something that probably happens a lot and will continue to happen a lot?
- dahfizz 4y ago
  I don't see the issue. Let's put all subtleties about Unix directories to the side. Zoom wanted to change the permissions of a file so that only root could access it. The obviously correct way to do that is to simply change the permissions of the file. Even if their solution of putting the file in a root dir worked the way they expected, it would be a circuitous and hacky solution. > sounds like a lot of reliance on people knowing and wanting to do the right thing? At a certain point, people need to have basic knowledge. There's a lock on your front door. It does not lock when you turn your lights off. The lock maker is not responsible if you expected it to.
  - mnw21cam 4y ago
    > The obviously correct way to do that is to simply change the permissions of the file. Obvious, but incorrect. As pointed out elsewhere, the permission check is done when a process opens a file, not when it performs read/write operations. So, an attacker could get a legitimate file, open in for writes, trigger the zoom update on it, zoom would then change the permissions to prevent writes, and then the attacker could modify the file using its already-open file handle.
InitialBP 4y ago
I'm not sure about all languages but this actually caught me by surprise. When you do a 'mv' command (tested on macos) it does not retain file permissions by default. You actually need to pass a special flag in order to do so. Objective C does retain perms by default using some common move techniques.
- dmd 4y ago
  What? Yes it does. You are confusing mv and cp.
  - rileymat2 4y ago
    This is a pretty good example. Sure, we should know our tools, but This is not intuitive behavior if you don't know. https://superuser.com/questions/101676/is-there-some-difference-between-mv-and-cp-rm-the-old-file-on-unix https://superuser.com/questions/101676/is-there-some-differe... It is not until the last comment of the accepted answer that you get to the difference in permissions. (along with the answers that are not accepted as best)
  - mnw21cam 4y ago
    Or the parent could be trying to mv a file from one filesystem to another. In that case, mv will have to revert to a copy-then-delete operation, and the user may not have the permissions necessary to set up the new file with all the same metadata as the original.
    - dmd 4y ago
      Good point.
- dahfizz 4y ago
  Whatever library or tool you use will just call the `rename` syscall. As you would expect, rename simply renames a file. It deletes the old directory entry and creates a new one. If you're using a library or tool to do this for you, you should know what it's doing.
dahfizz 4y ago
Yup, this is a very common misconception. In Unix, directories are not folders. Directories are literally a directory, like a phone book. It lists files and their location on disk. A directory doesn't contain any other files. Moving a file from one directory to another only modifies the directories, not the file itself. https://unix.stackexchange.com/questions/684122/what-permissions-on-a-file-or-directory-are-needed-to-cp-mv-and-rename-or-make https://unix.stackexchange.com/questions/684122/what-permiss...
- Dylan16807 4y ago
  So what? Windows likes the word folders but it works the same way. And you could easily have file access permissions depend on the directory if you wanted to.
  - dahfizz 4y ago
    > So what? Using the "folder" mental model leads to exactly the bugs in TFA. "Oh, the root folder can only be accessed by root, so if I put a file _inside_ that folder it will be protected". Thats not how it works. > And you could easily have file access permissions depend on the directory if you wanted to. No, because you can have multiple links in multiple directories all pointing to the same file.
    - Dylan16807 4y ago
      > Using the "folder" mental model leads to exactly the bugs in TFA. "Oh, the root folder can only be accessed by root, so if I put a file _inside_ that folder it will be protected". Thats not how it works. I don't really see the logic that way. Even if it was "inside", this permission failure would still happen. And directories, if used properly, can protect a 777 file from being changed. The error in the mental model is in how permissions work, not how files are organized. > No, because you can have multiple links in multiple directories all pointing to the same file. Well I put the word "access" there to try to be clearer. If you as system designer wanted to, you could have the path you take to a file affect permissions, even with the 'directory' model and multiple hard links. Heck, you could have permissions be on links instead of on files. YOLO.

pleb_nz 4y ago

I might be misunderstanding what you are saying, but it sounds like a lot of reliance on people knowing and wanting to do the right thing?

jacquesm 4y ago
Most of unix is like that though.
- hungryforcodes 4y ago
  This cannot be said enough.
zbird 4y ago
I'm not sure what you're suggesting. Would you go to a doctor who doesn't know or want to do the right thing?
- stevehawk 4y ago
  No, we go to facebook sir.
- whatshisface 4y ago
  Yes, and the way you'd end up doing that is by not having doctor telepathy.
- pleb_nz 4y ago
  So how do you prevent bad actors from abusing this and/or train every developer on the planet to ensure they do they follow the right processes. Sounds like its something that probably happens a lot and will continue to happen a lot?
dahfizz 4y ago
I don't see the issue. Let's put all subtleties about Unix directories to the side. Zoom wanted to change the permissions of a file so that only root could access it. The obviously correct way to do that is to simply change the permissions of the file. Even if their solution of putting the file in a root dir worked the way they expected, it would be a circuitous and hacky solution. > sounds like a lot of reliance on people knowing and wanting to do the right thing? At a certain point, people need to have basic knowledge. There's a lock on your front door. It does not lock when you turn your lights off. The lock maker is not responsible if you expected it to.
- mnw21cam 4y ago
  > The obviously correct way to do that is to simply change the permissions of the file. Obvious, but incorrect. As pointed out elsewhere, the permission check is done when a process opens a file, not when it performs read/write operations. So, an attacker could get a legitimate file, open in for writes, trigger the zoom update on it, zoom would then change the permissions to prevent writes, and then the attacker could modify the file using its already-open file handle.

InitialBP 4y ago

I'm not sure about all languages but this actually caught me by surprise. When you do a 'mv' command (tested on macos) it does not retain file permissions by default. You actually need to pass a special flag in order to do so. Objective C does retain perms by default using some common move techniques.

dmd 4y ago
What? Yes it does. You are confusing mv and cp.
- rileymat2 4y ago
  This is a pretty good example. Sure, we should know our tools, but This is not intuitive behavior if you don't know. https://superuser.com/questions/101676/is-there-some-difference-between-mv-and-cp-rm-the-old-file-on-unix https://superuser.com/questions/101676/is-there-some-differe... It is not until the last comment of the accepted answer that you get to the difference in permissions. (along with the answers that are not accepted as best)
- mnw21cam 4y ago
  Or the parent could be trying to mv a file from one filesystem to another. In that case, mv will have to revert to a copy-then-delete operation, and the user may not have the permissions necessary to set up the new file with all the same metadata as the original.
  - dmd 4y ago
    Good point.
dahfizz 4y ago
Whatever library or tool you use will just call the `rename` syscall. As you would expect, rename simply renames a file. It deletes the old directory entry and creates a new one. If you're using a library or tool to do this for you, you should know what it's doing.

dahfizz 4y ago

Yup, this is a very common misconception. In Unix, directories are not folders. Directories are literally a directory, like a phone book. It lists files and their location on disk. A directory doesn't contain any other files. Moving a file from one directory to another only modifies the directories, not the file itself. https://unix.stackexchange.com/questions/684122/what-permissions-on-a-file-or-directory-are-needed-to-cp-mv-and-rename-or-make https://unix.stackexchange.com/questions/684122/what-permiss...

Dylan16807 4y ago
So what? Windows likes the word folders but it works the same way. And you could easily have file access permissions depend on the directory if you wanted to.
- dahfizz 4y ago
  > So what? Using the "folder" mental model leads to exactly the bugs in TFA. "Oh, the root folder can only be accessed by root, so if I put a file _inside_ that folder it will be protected". Thats not how it works. > And you could easily have file access permissions depend on the directory if you wanted to. No, because you can have multiple links in multiple directories all pointing to the same file.
  - Dylan16807 4y ago
    > Using the "folder" mental model leads to exactly the bugs in TFA. "Oh, the root folder can only be accessed by root, so if I put a file _inside_ that folder it will be protected". Thats not how it works. I don't really see the logic that way. Even if it was "inside", this permission failure would still happen. And directories, if used properly, can protect a 777 file from being changed. The error in the mental model is in how permissions work, not how files are organized. > No, because you can have multiple links in multiple directories all pointing to the same file. Well I put the word "access" there to try to be clearer. If you as system designer wanted to, you could have the path you take to a file affect permissions, even with the 'directory' model and multiple hard links. Heck, you could have permissions be on links instead of on files. YOLO.