Date: Mon, 25 Nov 1996 11:51:39 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: sprice@hiwaay.net (Steve Price) Cc: hackers@Freebsd.org Subject: Re: looking for an idea Message-ID: <199611251651.LAA06060@skynet.ctr.columbia.edu> In-Reply-To: <Pine.OSF.3.94.961125095405.14763V-100000@fly.HiWAAY.net> from "Steve Price" at Nov 25, 96 10:05:41 am
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Steve Price had to walk into mine and say: > On Mon, 25 Nov 1996, Bill Paul wrote: > > # Of all the gin joints in all the towns in all the world, Steve Price had > # to walk into mine and say: > # > # What you're suggesting is basically security through obscurity. > # This would only work if we were a commercial OS like Slowlaris where > # source code is not available and the vendor intentionally fails to > # document the unerlying interface. Since we provide all source code, > # there's nothing to stop the user from splitting the RPC library out > # of the libc source tree (or making his own libc), modifying a few > # things, and then linking a malicious program that doesn't play by > # the rules. > # > # What I want is a way for keyserv to learn the UID of the caller that > # can't be spoofed unless an attacker can: > # > # - compromise keyserv itself > # - compromise the kernel > # - break root through some other means, in which case all bets are off > # anyway > # > > Ah, right you are. They could only compromise their own box by > twiddling and recompiling the source, unless of course keyserv > was running on some remote machine and they compromised the > keyserv library routines to send pid=1 which is guaranteed to be > root privileged. So you are right definitely right. Please can > my suggestion and label it as 'fit for smudgens only'. :) Well, you'd be surprised at how many commercial OS vendors will actually do stuff like that :) > # Again, it seems like the SysV IPC system calls are the only ones that > # do what I want, which is really too bad. You'd think BSD would have > # something equivalent. > # > > It's a crying shame. Hmm, I wonder how SysV's IPC system calls > get the pid then or do they. I don't profess to know a great deal > about IPC but you have peaked my interest, so off I go to dig up some > dirt. > > Steve Well, since they're system calls, they can look at the proc structure of the calling process and assign things accordingly. For example, when you call msgget() to create a message queue, the kernel creates a msqid_ds structure which contains an ipc_perm structure that tells you who created the message queue, who the current owner of the queue is (you can give ownership to someone else), what the access rights are, and some other useful tidbits. The msqid_ds structure itself has other information, like what was the last PID to do a msgrcv() on the message queue and who was the last PID to do a msgsnd(). All of this is set up inside the kernel, beyond the control of the caller. And the cuid (creator UID) in the ipc_perm structure can't be changed by the caller. What I'm experimenting with now is to have the caller (B) create a message queue and send a message containing its PID. The server (A) then reads the message from the queue and does an IPC_STAT to read the msqid_ds structure. This tells is the UID of the caller that created the queue, and the PID of the last person to use it. If the PID in the structure doesn't match the one sent in the message, A rejects the request. I still don't think this is 100% correct though. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611251651.LAA06060>