Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Nov 2000 10:12:50 +0100
From:      Stefan `Sec` Zehl <sec@42.org>
To:        Peter Pentchev <roam@orbitel.bg>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: changing a running process's credentials
Message-ID:  <20001116101250.A14200@matrix.42.org>
In-Reply-To: <20001115190135.E309@ringworld.oblivion.bg>; from roam@orbitel.bg on Wed, Nov 15, 2000 at 06:02:22PM %2B0100
References:  <20001115161316.C309@ringworld.oblivion.bg> <20001115190135.E309@ringworld.oblivion.bg>

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

A few years ago (Feb-1997 on FreeBSD-2.1.0) i wrote a little
proof-of-concept program to show that write access means instant root.

It uses stolen parts from the kvm lib and /bin/ps to do it.
I ported it to FreeBSD-3.2 a year ago, and it compiles and runs on 4.1
also.
I found it really handy when I start to edit a file to which i have no
write access. I can promote vi to root, and write the file instead of
fiddling around with temp-files ;-)

I've put the source at <ftp://ftp.42.org/pub/B/presto/presto-1.1.tar.gz>;
in case anyone wants it.

Of course it will only work as root, as write access to /dev/kmem is
needed. Do not make /dev/kmem group or even world writable ;-)

If this code is usefull for anyone else, i'd be happy to hear about it
;-)

CU,
    Sec
-- 
My biggest problem was when I screwed up the device driver for my eyelids
I couldn't open my eyes to debug them.


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?20001116101250.A14200>