Proposing to host system-auth-agent in fdo

[Carlos Garnacho]

On Wed, 2004-10-13 at 18:11 +0200, Alexander Larsson wrote:
> On Wed, 2004-10-13 at 17:35 +0200, Carlos Garnacho wrote:
> > On Wed, 2004-10-13 at 10:17 +0200, Alexander Larsson wrote:
> > > On Tue, 2004-10-12 at 19:05 +0200, Carlos Garnacho wrote:
> > > 
> > > > In order to avoid malicious use of the program/API, there's a list of
> > > > applications that are allowed to use the program, this list can be only
> > > > handled by the root user, and the package already provides 2 commands to
> > > > install/uninstall applications in that list (ideally, this will be
> > > > handled transparently, during make install, rpm -i, dpkg -i, ...), so
> > > > any application using this program will be there under the root user
> > > > consent.
> > > 
> > > I'd like to point out that the way this is handled:
> > > 
> > > static char*
> > > get_calling_app (void)
> > > {
> > >   pid_t ppid = 0;
> > >   char  path[PATH_MAX], *link;
> > >   int   length;
> > > 
> > >   ppid = getppid ();
> > >   sprintf (path, "/proc/%d/exe", ppid);
> > >   link = (char *) malloc (sizeof (char) * PATH_MAX);
> > >   
> > >   length = readlink (path, link, PATH_MAX);
> > > 
> > > Isn't very secure. Basically, to overcome it you only need to do:
> > > LD_PRELOAD=/tmp/evil_code.so /usr/bin/trusted_binary
> > 
> > While it's true that the program should unset those vars before exec'ing
> > the called application, the loader ignores any LD_PRELOAD or
> > LD_LIBRARY_PATH envvar if the running program is setuid/setgid, so it's
> > not an inmediate problem
> 
> I'm not sure i understand what you mean. Surely, if the app is setuid
> already we wouldn't need system-auth-agent. I though we had the case of:
> a trusted app, say /usr/bin/control-center can use system-auth-agent to
> launch another app (say /usr/bin/update-config) as root. However, other
> apps will be denied the right to start update-config as root. 

Sorry, my fault, when I wrote "the program", I meant
"system-auth-agent", the thing is that modern loaders
(/lib/ld-linux.so.X in the linux case) will ignore those envvars if the
running program has the setuid bit on (in this
case /usr/sbin/system-auth-agent). Such envvars will be propagated to
the program that's exec()'ed, but the system-auth-agent will be able to
disable them before exec()to prevent malicious use.

So this use case would be:

1) weird user runs LD_PRELOAD=evil.so /usr/bin/control-center, to change
getuid calls, to change the program that the system auth agent is going
to call, or whatever.

In this stage control-center may be affected by LD_PRELOAD, as always,
but it's running with user privileges, so it's not a bigger deal than
what it's now.

2) control-center does the call to the auth agent (whether directly by
evil code, through the API, or whatever).

3) the auth-agent is setuid, so isn't affected by LD_PRELOAD, checks
that control-center is authorized to use it, checks that the called
application is authorized for the calling user, if it isn't then ask for
the root password.

4) system-auth-agent disables dangerous envvars (this doesn't happen
ATM), and then exec()s the called application.

I hope that this clarifies that all the important checks are done in the
setuid program provided by the auth agent, which isn't theorically
affected by the LD_PRELOAD stuff, and that it will only run things
without being asked for password once the user enters the root password
at least one time and explicitly says that he's allowed to do this task.

	Carlos

> 
> In this case, any app could start update-config by launching
> LD_PRELOAD=evil.so /usr/bin/control-center and have a global constructor
> in evil.so that gets run before main(). control-center is not setuid
> here, nor is there a place where system-auth-agent could unset
> LD_PRELOAD.
>  
> > > Furthermore, the /proc use is linux-only.
> > 
> > I've found the equivalence in FreeBSD 5.3Beta1, and I'm sure that
> > Solaris gets this info from /proc too, it was created for things like
> > this
> > 
> > This /proc use might be a problem when/if there are python/perl/...
> > bindings, because that symlink would point to the interpreter, but I'm
> > sure that it can be fixed with a plugin system (or simply custom
> > functions) to parse /proc/$pid/cmdline. But anyway, I think that it's
> > the most secure way to know that the app is authorized to use the agent
> 
> I agree that its currently the best way to try to authorize apps (gnome-
> keyring uses it too). I'm just saying, its not perfect.
>  
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc 
>                    alexl at redhat.com    alla at lysator.liu.se 
> He's a scarfaced guitar-strumming card sharp who knows the secret of the alien 
> invasion. She's a psychotic thirtysomething soap star with an evil twin 
> sister. They fight crime! 
>