Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Nov 2000 19:01:35 +0200
From:      Peter Pentchev <roam@orbitel.bg>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: changing a running process's credentials
Message-ID:  <20001115190135.E309@ringworld.oblivion.bg>
In-Reply-To: <20001115084722.I29448@fw.wintelcom.net>; from bright@wintelcom.net on Wed, Nov 15, 2000 at 08:47:22AM -0800
References:  <20001115161316.C309@ringworld.oblivion.bg> <20001115084722.I29448@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 15, 2000 at 08:47:22AM -0800, Alfred Perlstein wrote:
> * Peter Pentchev <roam@orbitel.bg> [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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001115190135.E309>