From owner-freebsd-hackers Wed Nov 15 9: 2: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (pool237-tch-1.Sofia.0rbitel.net [212.95.170.237]) by hub.freebsd.org (Postfix) with SMTP id C037937B4C5 for ; Wed, 15 Nov 2000 09:02:00 -0800 (PST) Received: (qmail 14273 invoked by uid 1000); 15 Nov 2000 17:01:36 -0000 Date: Wed, 15 Nov 2000 19:01:35 +0200 From: Peter Pentchev To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: changing a running process's credentials Message-ID: <20001115190135.E309@ringworld.oblivion.bg> Mail-Followup-To: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG References: <20001115161316.C309@ringworld.oblivion.bg> <20001115084722.I29448@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001115084722.I29448@fw.wintelcom.net>; from bright@wintelcom.net on Wed, Nov 15, 2000 at 08:47:22AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 15, 2000 at 08:47:22AM -0800, Alfred Perlstein wrote: > * Peter Pentchev [001115 06:19] wrote: > > All right, feel free to flame me a LOT for what follows :) > > No need for that. (yet) :-) ..possibly because I did not make my intentions clear enough :) > > There are situations (at least I could think of some :) where it is necessary > > to change a running process's credentials. I'm thinking specifically of the > > effective UID and GID, but I might have to tinker with the real and saved > > UID's, too. > > Well there's setuid for you. Hmm.. I've also received two private mails so far, pointing me to setuid(). The problem is, I want to force a new UID on *another* process without its knowledge. setuid() only works on the process invoking it, so both the 'force' and the 'without its knowledge' part fall by the wayside :( > > > As far as I can see, FreeBSD (nor any other Unix system I'm aware of) does not > > provide a way to do this (short of writing to /dev/kmem ;). If a new syscall > > should be implemented to this end, would it be enough to change a struct > > proc's p_cred member, its pc_ucred and such, or would that raise hell all over > > the process table? I see the comments mentioning 'possibly shared' > > credentials - does this mean that I can inadvertently change the credentials > > of a whole process children/siblings tree? That does not sound too good - > > how do I go about taking a single process's credentials out - just allocate > > a new pcred/ucred structure? > > Struct ucred is read-only, that would mean that strange things may > happen, fortunatly at the moment most access control checks are > only done at file open/socket bind time, so that if your cred > changes you should still have access to it. > > > And yes, I'm quite aware of the security implications of something like > > that.. let's just say I like playing with fire in a controlled environment :) > > (famous last words..) > > Well there wouldn't be any security implications if done right... The security implications I meant have to do with the ability to provide either a tool or a sysctl to change the uid of any running process on the system - that would have to include stringent controls on exactly who and why uses this tool/sysctl. I have some ideas about this, but they need some more grinding before they're ready to be tossed at the world for discussion (and dissing ;) > What comes to mind is using the cmsg stuff that's normally used to > pass file descriptors and authentication information to pass the > ability to setuid over to another application over a unix domain > pipe. The recieving process would read using recvmsg determine if > the passed uid is 'ok' (the kernel would hold it in the proc struct > in a temporary), if it 'wanted' this uid it could then call some > variation of setuid to switch to this recieved uid. Yeah; problem is, as I said above, I do not want the receiving process to do anything special - just to wake up with a shiny new uid (this would probably surprise the hell out of most programs, but oh well :) G'luck, Peter -- If I had finished this sentence, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message