On Wed, Nov 15, 2000 at 08:47:22AM -0800, Alfred Perlstein wrote:
> * Peter Pentchev <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
