Wietse Venema asked me what my ideas were for inter-privilege communication. These are the ideas I sent to him. I'm sending it to Bugtraq also so that, if approved, any unnoticed holes could be pointed out to me. On Wed, 6 Jan 1999, D. J. Bernstein wrote: > However, in most cases, the daemon needs to know who it's talking to, > for access control or for accounting. That's why I want a getpeeruid() > routine returning the uid that called connect(). Identifying a local user connected via a unix socket is something that would come in handy for a lot of programs. A portable library designed to do this from a common interface would help. Systems that don't implement something similar to getpeeruid() could be shimmed by using a privileged daemon to drop a random key into files readable only by the user and the program requesting authentication; the client presents the key to the authenticating service for verification. The attack with this method is DoS: request lots of authentication. However, using a drop directory described in my next scheme, perhaps the work of generating the key could be left to the client. The authenticating service would simply compare the socket key with the filesystem key and reply "good" or "bad". "Secure" Drop Directories Wietse Venema said that daemons were not a reliable way to queue mail, since the system may not always be in multi-user mode. Because set[ug]id gateways have been decided to be too pourous, and world-writeable drop directories have other problems, I looked for a better way to (ab)use the filesystem into providing inter-uid IPC. Here it is: A pre-generated set of directories, each individually owned by 0-max of uid_t. They are only readable by the owning uid and the service the files are being sent to (via group ownership). To prevent the OS from thrashing when it tries to index the directories, they should be hashed. When a user wishes to drop a file into the queue, he simply writes it to his directory in the tree. How would the queue daemon pick up the messages? Obviously searching through so many directories would be a difficult (but not impossible) task. Thankfully, a way to "hint" to the daemon and help it narrow it's search can be shimmed through the FS too. At each level of the hashed directories, a file "CHANGED" could exist. When the last access time of a "CHANGED" file increments, the queue daemon could recurse into the tree, following the "CHANGED" files like breadcrumbs to the eventual queued message. A message dropper would simply have to read each appropriatte "CHANGED" file to update it's access time. A lame attacker could waste the queue daemon's time by reading many "CHANGED" files. Perhaps if this is seen as a damaging attack the name of the breadcrumbs could be obscured by blocking directory read permissions and having each path have a unique breadcrumb filename combination. All this trouble to make a secure & robust drop directory in UNIX. If the existent users could be polled, the trouble of creating a large hierarchy of directories and hashing them could be avoided. Only existent users need have a drop directory. Home directories you say? They might often be remotely mounted and unavailable in single user mode. Creating a drop directory with account creation would help avoid all this complication. > Anyway, I've set up a web page discussing various IPC mechanisms from > the writing-daemons-that-manage-restricted-files point of view: > > http://pobox.com/~djb/docs/secureipc.html > > Please let me know if you have any updates. I hope this is a worthwhile contribution. -vermontat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:27:45 PDT