5 ms·

How can malware delete a keychain item if it is not on the ACL?

gpvos 11y ago
Apparently everyone can. That's the bug, or at least a big part of it. There is precedent for this, for example in the Unix filesystem permissions: to be able to delete a file, you need write access to its parent directory; the permissions of the file itself are not taken into account.
- smtddr 11y ago
  >>There is precedent for this, for example in the Unix filesystem permissions: to be able to delete a file, you need write access to its parent directory; the permissions of the file itself are not taken into account. My mind has been blown. I can delete this .txt as the user "pikachu". I had no idea. pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ ls -la total 8 drwxrwxr-x 2 pikachu pikachu 4096 Jun 17 08:48 . drwxr-xr-x 3 pikachu pikachu 4096 Jun 17 08:48 .. -rw-r--r-- 1 root root 0 Jun 17 08:48 gogogadgetarms.txt pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ rm gogogadgetarms.txt rm: remove write-protected regular empty file ‘gogogadgetarms.txt’? y pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ ls -la total 8 drwxrwxr-x 2 pikachu pikachu 4096 Jun 17 08:52 . drwxr-xr-x 3 pikachu pikachu 4096 Jun 17 08:48 .. pikachu@POKEMONGYM ~/tmp3/pikachuFolder $
  - gpvos 11y ago
    The sticky bit, often applied to directories like /tmp, fixes this: https://en.wikipedia.org/wiki/Sticky_bit https://en.wikipedia.org/wiki/Sticky_bit .
  - syncsynchalt 11y ago
    The thinking is that if you own the directory you own the ability to remove things from it. It gets reported as a bug quite often though.
- carlosrg 11y ago
  Well, the UNIX case is not a bug, it's by design. A directory is a list of files, so you remove a file by removing it from that list, the directory. The permissions of the file itself are for access/modifying of the contents of the file itself.
  - acdha 11y ago
    That's technically correct but it violates the principle of least surprise. Most users find the behaviour unexpected even though it's fairly easy to remember and real-world analogues abound (e.g. you can shred an envelope without reading the contents). It's not clear to me that this is a common-enough situation to warrant changing anything so the best answer is probably to make sure documentation is easily found.
    - logfromblammo 11y ago
      It seems like under these conditions-- 1. The user has write permission for the directory. 2. The user does not have write permission for the file. 3. The file has only one hard link. 4. The user deletes the file. --that the last hard link should be moved to ~owner home directory, rather than deleted. Otherwise, I don't see a problem.
      - acdha 11y ago
        Again, I'm not sure this happens very often – most projects have tended to focus on avoiding cases where you have users crossing security boundaries like this. At the very least, setting the sticky bit seems to avoid a great deal of potential confusion. I haven't thought about this in depth but here are the edge cases which come to mind on first thought with your proposal: 1. What happens if that file is on a different filesystem than the owner's home directory? 1a. What if the home directory is on a filesystem which doesn't have room? 1b. What happens if that would cause the user to exceed a size or inode quota? 2. How does this interact with e.g. lockd in an NFS environment? 3. How does it get a filename / how do we avoid security issues? For example, if I have write access to a directory I can rename the file to, say, .bashrc before I call unlink() so this would probably require generated some sort of reasonably informative name which can't collide ("deleted-by-<uid>-<hostname>-<inode>-<SHA-256>-<sequence>"?). You could probably handle some of this by following the tradition of `lost+found` and moving it to a directory on the same filesystem which has the sticky bit set.

gpvos 11y ago

Apparently everyone can. That's the bug, or at least a big part of it. There is precedent for this, for example in the Unix filesystem permissions: to be able to delete a file, you need write access to its parent directory; the permissions of the file itself are not taken into account.

smtddr 11y ago
>>There is precedent for this, for example in the Unix filesystem permissions: to be able to delete a file, you need write access to its parent directory; the permissions of the file itself are not taken into account. My mind has been blown. I can delete this .txt as the user "pikachu". I had no idea. pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ ls -la total 8 drwxrwxr-x 2 pikachu pikachu 4096 Jun 17 08:48 . drwxr-xr-x 3 pikachu pikachu 4096 Jun 17 08:48 .. -rw-r--r-- 1 root root 0 Jun 17 08:48 gogogadgetarms.txt pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ rm gogogadgetarms.txt rm: remove write-protected regular empty file ‘gogogadgetarms.txt’? y pikachu@POKEMONGYM ~/tmp3/pikachuFolder $ ls -la total 8 drwxrwxr-x 2 pikachu pikachu 4096 Jun 17 08:52 . drwxr-xr-x 3 pikachu pikachu 4096 Jun 17 08:48 .. pikachu@POKEMONGYM ~/tmp3/pikachuFolder $
- gpvos 11y ago
  The sticky bit, often applied to directories like /tmp, fixes this: https://en.wikipedia.org/wiki/Sticky_bit https://en.wikipedia.org/wiki/Sticky_bit .
- syncsynchalt 11y ago
  The thinking is that if you own the directory you own the ability to remove things from it. It gets reported as a bug quite often though.
carlosrg 11y ago
Well, the UNIX case is not a bug, it's by design. A directory is a list of files, so you remove a file by removing it from that list, the directory. The permissions of the file itself are for access/modifying of the contents of the file itself.
- acdha 11y ago
  That's technically correct but it violates the principle of least surprise. Most users find the behaviour unexpected even though it's fairly easy to remember and real-world analogues abound (e.g. you can shred an envelope without reading the contents). It's not clear to me that this is a common-enough situation to warrant changing anything so the best answer is probably to make sure documentation is easily found.
  - logfromblammo 11y ago
    It seems like under these conditions-- 1. The user has write permission for the directory. 2. The user does not have write permission for the file. 3. The file has only one hard link. 4. The user deletes the file. --that the last hard link should be moved to ~owner home directory, rather than deleted. Otherwise, I don't see a problem.
    - acdha 11y ago
      Again, I'm not sure this happens very often – most projects have tended to focus on avoiding cases where you have users crossing security boundaries like this. At the very least, setting the sticky bit seems to avoid a great deal of potential confusion. I haven't thought about this in depth but here are the edge cases which come to mind on first thought with your proposal: 1. What happens if that file is on a different filesystem than the owner's home directory? 1a. What if the home directory is on a filesystem which doesn't have room? 1b. What happens if that would cause the user to exceed a size or inode quota? 2. How does this interact with e.g. lockd in an NFS environment? 3. How does it get a filename / how do we avoid security issues? For example, if I have write access to a directory I can rename the file to, say, .bashrc before I call unlink() so this would probably require generated some sort of reasonably informative name which can't collide ("deleted-by-<uid>-<hostname>-<inode>-<SHA-256>-<sequence>"?). You could probably handle some of this by following the tradition of `lost+found` and moving it to a directory on the same filesystem which has the sticky bit set.