Re: Using gconf in setuid program?

[David Zeuthen <david fubar dk>]

On Tue, 2005-06-28 at 08:22 +0100, Mark McLoughlin wrote:
> Hey David,
> 	Interesting question; thinking it through:

Hey Mark,

>  
>  - You'd want to be sure to read the system-wide config only:
>      + You need to do this because you don't want to read root's config 
>        and the parsing of the GConf path file uses env variables
>      + There should be a way of doing that apart from loading
>        xml:readonly:/etc/gconf/gconf.xml.defaults since the system-wide 
>        config isn't guaranteed to only be there.
>      + For now, you'd have to use xml:readonly:/etc/gconf/gconf.xml.defaults
>        but that's not suce a bad thing since you can be sure what 
>        backend is loaded and that the config is read from a 
>        well-defined location.

Well, ideally the setuid program wants to see exactly the same settings
as the user sees (e.g. mandatory > per-user > defaults) to enforce the
same policy as the rest of the bits using these keys.

For example, in the gnome-mount case, I want a key
named /system/storage/show_internal_harddisks that, only if TRUE, makes
Nautilus shows your partitions from internal hard disks (e.g. so I can
see my Windows or Mac OS X partition). 

Thus, I want the gnome-mount (and by extension gnome-mount-helper) to
see and respect (e.g. refuse to mount if it is FALSE) the same value of
the user notwithstanding the fact that the user may or may not (if it's
set in the mandatory set) change it himself.

>   - You'd want to use direct mode rather than gconfd-2:
>      + Obviously don't want another process
>      + There'd be much more code to audit if you didn't
>      + gconf_engine_get_local() isn't in the public API, though
> 
>  - The total amount of code to audit given direct mode, single data
>    source and using GConfEngine to get a bool is not huge at all
> 
>  - I'm not 100% sure whether g_module_open() with a known-safe absolute 
>    path is secure from a setuid() program - pretty sure it is looking 
>    at glibc's ELF loader code, but that would need to be checked more 
>    carefully.
> 
> 	So, I'm not seeing obviously wrong with using libgconf in direct mode
> with a hard-coded data source address. But it would certainly be useful
> to get more people to look at it before going ahead with it.

What about my idea to just call gconftool-2 with a well-know environment
and with all privileges dropped? It seems that if this works I wouldn't
need to pull in libglib-2, libgconf-2 and much other code. It might be
less efficient but for my specific application this is sort of a
non-issue.

The setuid code I have today is about 500 lines of C with libdbus being
the only real dependency (and libdbus is specifically written with
paranoia in mind), thus I only really need to audit 500 lines of code
myself.

    David