Keychain items have access control lists, where they can whitelist applications, usually only themselves. If my banking app creates a keychain item, malware will not have access. But malware can delete and recreate keychain items, and add both itself and the banking app to the ACL. Next time the banking app needs credentials, it will ask me to reenter them, and then store them in the keychain item created by the malware.
(This would only show if you've been exploited already, not that some app is capable of doing it.)
What would indicate a compromise?
`security` is a built-in system utility, basically Keychain Access for terminal, the same way that `diskutil` is Disk Utility but in the terminal.
cat results.txt | grep -A 20 'applications' |grep \[0-9\]: | grep -v entry | grep -v description | cut -d\ -f14- | sort | uniq
- up to 10 apps in the ACL ( the max I saw in mine was 7 )
- the word 'entry' or 'decription' was no present in the app name security dump-keychain -a > keychain-results.txt
grep -P '(^(class|keychain):|\s+("(svce|acct)"|0x0000000(1|7)) <blob>="[^"]*"|^\s+applications \(([2-9]|[0-9]{2,})\):|^\s+[0-9]+:)' keychain-results.txt | \
perl -pe 's/\n/\0/g' | perl -pe 's/\0keychain:/\nkeychain:/g' | \
grep -aP 'applications \(([2-9]|[0-9]{2,})\):' | \
sort -u | perl -pe 's/\0/\n/g'That said, this doesn't fix the case tptacek listed where a malicious app could include helpers registered to the bundle ID of another app and those helpers would be automatically added to the ACL of those other apps. If that's an accurate description it sounds like something only Apple can fix.
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 $It gets reported as a bug quite often though.
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.
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.
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.
For me, that is worse, as when "Next time the banking app needs credentials, it will ask me to reenter them" would occur, my reaction would be "I do not know my password; it's in the keychain" (for most services)
Mac Outlook have (for unknown reasons) been asking me for my domain password to store it into the keychain, the last week, which surprised me at the time.