Re:Keeping Memory Contents Secret
by tzs on Monday November 25, 2019 @01:17PM
(#21631058)
How about where you need some data that is available to all processes running under the same UID, but not to other processes? How do people handle that nowadays, especially on a generic server with no special cryptographic or security hardware?
To make it more interesting, assume that (1) the processes do not have a common ancestor running as that UID, and (2) if all processes with that UID exit, the secret should still be available if any new processes are started with that UID, and (3) the secret must be forgotten when the machine shuts down or loses power.
Assume that the secret should be safe from attackers who can run arbitrary code as other non-root users, who can force the machine to reboot, and who can steal the machine itself. (Stealing the machine causes it to lose power--no need to worry about a George Costanza/"Frogger" scenario).
For example, imagine a service implemented as a CGI that needs the keys for an encrypted database it uses, or needs the password for a service that it needs to access, using Apache using suEXEC to run this service's CGI under a dedicated UID.
It would seem that you need some kind of persistent storage. The first thing that comes to mind is a file. It can be owned by the UID of the CGI, and mode 0400. This doesn't meet the requirement of the secret being forgotten on shut down, though.
Would good old fashioned System V shared memory work for this? It has ownership and access control similar to files, so a shared memory segment owned by UID and mode 0600 should only be accessible to processes with the right UID (and root). It goes away when the machine shuts down. Linux's System V shared memory implementation adds a flag you can set via shmctl to keep it from swapping it.
Re:Keeping Memory Contents Secret
by AgentME on Monday November 25, 2019 @01:57PM
(#21631486)
It sounds like you want a file on a ram disk. Linux creates a ram disk by default in /dev/shm. You could create a file or directory there only accessible by a specific UID.
To make it more interesting, assume that (1) the processes do not have a common ancestor running as that UID, and (2) if all processes with that UID exit, the secret should still be available if any new processes are started with that UID, and (3) the secret must be forgotten when the machine shuts down or loses power.
Assume that the secret should be safe from attackers who can run arbitrary code as other non-root users, who can force the machine to reboot, and who can steal the machine itself. (Stealing the machine causes it to lose power--no need to worry about a George Costanza/"Frogger" scenario).
For example, imagine a service implemented as a CGI that needs the keys for an encrypted database it uses, or needs the password for a service that it needs to access, using Apache using suEXEC to run this service's CGI under a dedicated UID.
It would seem that you need some kind of persistent storage. The first thing that comes to mind is a file. It can be owned by the UID of the CGI, and mode 0400. This doesn't meet the requirement of the secret being forgotten on shut down, though.
Would good old fashioned System V shared memory work for this? It has ownership and access control similar to files, so a shared memory segment owned by UID and mode 0600 should only be accessible to processes with the right UID (and root). It goes away when the machine shuts down. Linux's System V shared memory implementation adds a flag you can set via shmctl to keep it from swapping it.