Proposing to host system-auth-agent in fdo

[Alexander Larsson]

On Fri, 2004-10-29 at 17:54 +0200, Carlos Garnacho wrote:
> hi!,
> 
> 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 [1] 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[0]
> 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[0] 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!