On Wed, 30 Aug 2000, Andreas Beck wrote:
> Security. LibGGI is - due to its dynamic loading mechanism and its external
> configurabilty via the environment - very unsuitable to be run suid.
>
> While most people here will agree, that there isn't much use in making
> LibGGI progs suid, SVGAlib users might think otherwise as well as some
> lazy people that would like to make something like ggipasswd or similar,
> without doing "the right thing" and split it into a front- and a backend.
I agree with you only on this very last point: for such a program, NOT
splitting it into a front- and back-end would be a bad security design
mistake. I don't think the current design of LibGGI needs more additional
security features - bad programs will always behave badly, whatever the
features of the libraries they use.
However, maybe LibGGI, like any other code, would benefit from some
security audit and review. Sure, as you say, it uses a lot of env.
variables and dynamic options, so there must be a good bunch of potential
buffer overflows and careless parsing still scattered in the code
presently. But IMO such audit should be done _before_ trying to add new
security-related features.
Anyway, as any OpenBSD fan would tell you: ALWAYS start with a security
audit of the source code, and settle the remaining issues when it's
finished -- next year!
Finally IIRC originally in the GGI+KGI project, security improvements
came primarily from the fact that KGI was providing kernel-controlled
access to the hardware. What is interesting with GGI+KGI is the ability
of a program to never run suid (even on behalf of another program,
like for X11 apps.)! People who only buys half of the project
should only get half of the advantages (guess to who I'm thinking :-).
Rodolphe
