Misconceptions regarding the KEK and DEK
The KEK is not meant to be stored, only the eDEK (encrypted DEK) is. The KEK is input once, and is used to decrypt the eDEK. The DEK is then kept in memory by whatever process requires it, as it is fundamentally necessary for a key to be present in memory in order to be used for decryption. The KEK should be kept in memory only long enough to decrypt the eDEK, then it should be overwritten (to prevent it from lingering in freed memory). As managing keys in memory can be difficult, with many ways to screw things up badly, I strongly recommend using existing software designed for this purpose. If you do not know how and why you should lock memory that will be holding key material, or how to ensure that
memset calls will not be optimized out when wiping key material from memory, you should not be implementing cryptosystems yourself. Use an existing solution, or at the very least a suitable high-end and easy-to-use crypto library.
Regarding your statement on shared memory, that depends on what you mean by shared memory. POSIX shared memory (shmem) is a method of storing objects in memory that any process with the proper permissions can access. It is similar to your idea of storing data in tmpfs, except POSIX shared memory uses a special API for accessing objects. In that case, storing something sensitive for a given user in shared memory may not be a great idea.
The other definition of shared memory is memory present in the address space of more than one process. A process must choose to share a given region of memory with another process, passing the
MAP_SHARED flag to
mmap when requesting memory from the kernel. Usually this is done by a parent process which then forks into two processes which share a specific region of memory. In this case, memory is only shared by processes which explicitly permit it.
It is necessary to define your threat model. Who are you protecting this data from? Where are they positioned in relation to the data? What level of access do they have? Generally, an operating system will already provide software-level access controls, making encryption the wrong tool for preventing a malicious process from accessing data that is being used elsewhere. Encrypted storage is designed to provide data-at-rest security, protecting the data on the hard drive, should it be stolen or otherwise fall into the wrong hands. For this threat model where encryption is meant to be used, you do not need to give the key to any more processes than are needed to actually read the database. Specifically, you should let the database software do the encryption and decryption, allowing anyone with permission to connect to the database server the ability to read the contents, subject to software-level permissions.