View source for Secure installation considerations

To prevent a wrong installation of gLExec, which could lead to easy exploitation of the computer system, an out side source must be able to verify the installation. Consider the use of tripwire, rpm --verify <rpm package name> or something.


At the moment the packages that we produce are without the setuid-bit on root. This means that an admin would need to run YAIM or the chmod command manually to get the setuid bit enabled on root. Because the deployment needs this post installation manipulation on the executable the rpm --verify (and Debian package equivalent) will inherently fail, because not only the hash of the binary also the file permissions are verified.


It's pointless for gLExec to provide a safe test in itself to signal its binary to be, for example, be world writable. If this test fails, you would send a strong signal to a potential attacker to rewrite the binary. On Linux systems and most Unix system the setuid-root bit is stripped when the image is rewritten, making it a harmless executable at best. However, this is not desired, but unavoidable to provide such a self test in gLExec itself.