Proposing to host system-auth-agent in fdo
alexl at redhat.com
Fri Oct 29 19:29:32 EEST 2004
On Fri, 2004-10-29 at 17:54 +0200, Carlos Garnacho wrote:
> On Mon, 2004-10-25 at 09:12 +0200, Alexander Larsson wrote:
> > On Sun, 2004-10-24 at 17:33 +0200, Carlos Garnacho wrote:
> > > On Mon, 2004-10-18 at 09:06 +0200, Alexander Larsson wrote:
> > > > On Sat, 2004-10-16 at 20:48 +0200, Carlos Garnacho wrote:
> > > >
> > > > > Ok, the program that uses the API could still be affected by LD_PRELOAD,
> > > > > but let's suppose the next scenario:
> > > > >
> > > > > Joe tries to do weird stuff, writes a .so file that replaces getuid()
> > > > > calls to impersonate Frank and tries to run "rm -rf /", runs
> > > > > control-center with LD_PRELOAD
> > > > >
> > > > > 1) system-auth-manager will still know which is the calling user, as it
> > > > > isn't affected by LD_PRELOAD
> > > > >
> > > > > 2) system-auth-manager will check that user Joe is allowed to run the
> > > > > "rm" command, if he isn't, the root password will be requested, and the
> > > > > whole LD_PRELOAD won't be effective at all.
> > > >
> > > > So, you're agreeing that the binary-name check doesn't help much? (Since
> > > > you brought up the uid check instead.)
> > >
> > > I've just uploaded the 0.0.2 version  which fixes this problem by
> > > linking statically the library by default (adding ~50KB to the binary
> > > size), one can still LD_PRELOAD to override read() and write() calls,
> > > but that problem is intrinsic to any graphical auth application.
> > I'm not sure how this helps anything? Its very easy to write a shared
> > library, that when LD_PRELOADed into an app runs before main() of the
> > app is even called (using constructors) and takes total control.
> > Basically you can write whatever application you want, doing whatever
> > you want. But instead of running it as "hostile-binary" you run it so
> > that it looks like whatever other binary you choose (e.g. /usr/bin/ls).
> > So, any system that depends on what executable a process was started as
> > is inefficient (at least if thats the only measure).
> Well, consolehelper can be LD_PRELOADed too, currently it takes argv
> and calls userhelper with that. Userhelper checks that the requested app
> has an entry in /etc/security/console.apps/ and runs it if so.
> I can LD_PRELOAD or code a bogus consolehelper in my path to run any
> other allowed command.
You don't even have to do that. argv is passed separately from the
binary name in execve(). However, consolehelper doesn't really do
anything priviledged, it just calls usermode -w pathname. So i'm not
sure why this matters.
Alexander Larsson Red Hat, Inc
alexl at redhat.com alla at lysator.liu.se
He's a benighted chivalrous librarian moving from town to town, helping folk
in trouble. She's a blind thirtysomething bounty hunter with a song in her
heart and a spring in her step. They fight crime!
More information about the xdg