8 ms·

> 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_ tha

> 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.
- dahfizz 4y ago
  >And directories, if used properly, can protect a 777 file from being changed. Could you explain how this would work?
  - Dylan16807 4y ago
    Say every hard link to the file is a descendant of a directory that blocks traversal. No subdirectories of those are already open, and the file is not already open. That keeps it safe, right? If there's any loopholes in that, they could be closed.
    - inkyoto 4y ago
      > Say every hard link to the file […] Ehr, no. Again, there are no files in the conventional sense in UNIX file systems. There are collections of disk blocks pointed to by an i-node and one or more directory entries pointing to an i-node. It is possible to have an i-node with 0 directory entries linking to it as well as multiple unrelated (i.e. not hard links but truly disjoint directory entries) directory entries referencing the same i-node; both are treated as file system errors by fsck and will be fixed up at the next fsck run. Yet, both scenarios can be easily reproduced (without corrupting the file system!) in a file system debugger and live on for a while. > […] a descendant of a directory that blocks traversal. No subdirectories of those […] Directory entries in a UNIX file system do not ascend nor descend, they are linked into one or more directories whether they form a hierarchy or not. A directory might be «protected» by, say, 700 permissions obscuring a particular directory entry, but if a hard link to the same i-node exists in a another unrelated directory outside the current hierarchy that has more permissive access, say 755, access to data blocks referenced to by an i-node has already leaked out.
      - mnw21cam 4y ago
        > multiple unrelated (i.e. not hard links but truly disjoint directory entries) directory entries referencing the same i-node That's what a hard link is. What we call hard links in Unix/Linux is when you have multiple distinct directory entries referencing the same inode.
      - Dylan16807 4y ago
        The other reply already covered the definition of hard links. It's a directory entry that points to an inode. And file system corruption is definitely a loophole. > Directory entries in a UNIX file system do not ascend nor descend, they are linked into one or more directories whether they form a hierarchy or not. All the filesystems I'm sufficiently aware of insist on directories being a tree. Every entry except the special .. descends in that tree. And each hard link is in a specific directory. > if a hard link to the same i-node exists in a another unrelated directory outside the current hierarchy that has more permissive access That's why I said every hard link to the file!
- SulphurCrested 4y ago
  > ... 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. There is a second possible misconception that I did touch on in my last paragraph, but didn't spell out. On Unix, the permissions check is done when you open the file, not when you perform the read or write. This means that a user who cannot currently open the file (because directory permissions mean they have no way to get to the inode) can nonetheless alter it now if they opened it when they could. So you could rename the file from the attacker's directory into your installer's private directory, verify its cryptographic signature, but then the attacker injects their malware into the file before you start copying, and you install the malware. Because the two common types of locks on Unix (BSD and POSIX record) are advisory, you can't just lock that file against writers before you check the signature. This is in contrast to Windows, where you can't even rename or delete the file if someone else has it open.
  - Dylan16807 4y ago
    Making sure it's not already open by someone else is definitely part of "used properly".
    - SulphurCrested 4y ago
      How do I do that? fstat(2) is no help on macOS, and even if it were would return false positives from things like backup and content indexers ("Time Machine" and "Spotlight" on macOS).
      - Dylan16807 4y ago
        You need to control the lifecycle of the file in some manner. Or force a reboot, I guess?

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.

dahfizz 4y ago
>And directories, if used properly, can protect a 777 file from being changed. Could you explain how this would work?
- Dylan16807 4y ago
  Say every hard link to the file is a descendant of a directory that blocks traversal. No subdirectories of those are already open, and the file is not already open. That keeps it safe, right? If there's any loopholes in that, they could be closed.
  - inkyoto 4y ago
    > Say every hard link to the file […] Ehr, no. Again, there are no files in the conventional sense in UNIX file systems. There are collections of disk blocks pointed to by an i-node and one or more directory entries pointing to an i-node. It is possible to have an i-node with 0 directory entries linking to it as well as multiple unrelated (i.e. not hard links but truly disjoint directory entries) directory entries referencing the same i-node; both are treated as file system errors by fsck and will be fixed up at the next fsck run. Yet, both scenarios can be easily reproduced (without corrupting the file system!) in a file system debugger and live on for a while. > […] a descendant of a directory that blocks traversal. No subdirectories of those […] Directory entries in a UNIX file system do not ascend nor descend, they are linked into one or more directories whether they form a hierarchy or not. A directory might be «protected» by, say, 700 permissions obscuring a particular directory entry, but if a hard link to the same i-node exists in a another unrelated directory outside the current hierarchy that has more permissive access, say 755, access to data blocks referenced to by an i-node has already leaked out.
    - mnw21cam 4y ago
      > multiple unrelated (i.e. not hard links but truly disjoint directory entries) directory entries referencing the same i-node That's what a hard link is. What we call hard links in Unix/Linux is when you have multiple distinct directory entries referencing the same inode.
    - Dylan16807 4y ago
      The other reply already covered the definition of hard links. It's a directory entry that points to an inode. And file system corruption is definitely a loophole. > Directory entries in a UNIX file system do not ascend nor descend, they are linked into one or more directories whether they form a hierarchy or not. All the filesystems I'm sufficiently aware of insist on directories being a tree. Every entry except the special .. descends in that tree. And each hard link is in a specific directory. > if a hard link to the same i-node exists in a another unrelated directory outside the current hierarchy that has more permissive access That's why I said every hard link to the file!
SulphurCrested 4y ago
> ... 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. There is a second possible misconception that I did touch on in my last paragraph, but didn't spell out. On Unix, the permissions check is done when you open the file, not when you perform the read or write. This means that a user who cannot currently open the file (because directory permissions mean they have no way to get to the inode) can nonetheless alter it now if they opened it when they could. So you could rename the file from the attacker's directory into your installer's private directory, verify its cryptographic signature, but then the attacker injects their malware into the file before you start copying, and you install the malware. Because the two common types of locks on Unix (BSD and POSIX record) are advisory, you can't just lock that file against writers before you check the signature. This is in contrast to Windows, where you can't even rename or delete the file if someone else has it open.
- Dylan16807 4y ago
  Making sure it's not already open by someone else is definitely part of "used properly".
  - SulphurCrested 4y ago
    How do I do that? fstat(2) is no help on macOS, and even if it were would return false positives from things like backup and content indexers ("Time Machine" and "Spotlight" on macOS).
    - Dylan16807 4y ago
      You need to control the lifecycle of the file in some manner. Or force a reboot, I guess?