TBH this is still possible in some scenarios, mostly when someone isn't using data protection and manually unlocked a local Keychain. It's pretty much the same as dumping LSASS memory on Windows when IOMMU isn't used, and in some cases even when IOMMU is used.
Yeah so it really depends on the local setup. Here's a wall of text if you're interested:
Say you do software development with a platform engineering and cloud flavour on top, you might be using aws-vault to keep access keys and SSO session keys in a dedicated keychain rather than in plaintext in ~/.aws/. That keychain has an ACL that only allows aws-vault to access it, and has a self-lock timeout of a few minutes. This is great, because it is pretty secure, there is nothing to 'steal' (even from an unlocked machine) and it's still extremely convenient.
However. Say you do this with an external non-TouchID keyboard, when the STS timeout expires and you need to re-authenticate, you also need to unlock the keychain for a few seconds so aws-vault can either read out the SSO session tokens or the static secret for non-SSO usage, and it has to write back the new STS session.
During that window, the keychain unlock from such a keyboard means manual password entry, which in turn means that has to be in memory for a bit. Because a legacy keychain doesn't use data protection (but if you create a new one you do have that option) it's essentially just an AES encrypted file on disk. Because humans aren't likely to remember an AES key, it's derived and wrapped so you have some KDF that uses a user-selected password, which has to be in memory for a bit while the key is unwrapped/derived. The AES key itself has to stay in memory the entire duration of the unlocked state of the keychain, because without the AES key it can't read or write secrets.
Technically, the same happens to encrypted disk images (the AES ones at least, other types I'm not 100% sure). The DEK has to stay in memory while it is in use. It's why Apple started using systems like cryptexes and SSVs so the container disk is almost irrelevant from an integrity point of view. Before that, encrypted disks were an all-or-nothing approach.
Yeah, it's a bit overloaded. There are keychains (.keychain files) and keychain items (secrets inside of them). The keychains are visible in the Keychain Access app, but also available in the 'security' command line. And then there are modern keychains, those are more like SQLite databases and those can have anything from SQLCrypt type of management to Secure Enclave DEKs.
Security is pretty difficult to get right, so many tradeoffs as well.
Top level = Keychain Access.app or the security CLI tool
Mid level = keychains (in flavours of files, core storage, data protection-enabled, and iCloud)
Item level = an entry inside a keychain
There is a sub-level as well, some software stores encoded data as a single item so when it's decrypted it's a bunch of different data, not a single secret, but technically the keychain system isn't aware of that anyway.
