Difference between revisions of "Secure installation considerations"
| Line 1: | Line 1: | ||
| − | To prevent a wrong installation of gLExec, which could lead to easy exploitation of the computer system, an | + | To prevent a wrong installation of gLExec, which could lead to easy exploitation of the computer system, an outside 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 | + | 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 but also the file permissions are verified. |
| − | + | Note that it is impossible for gLExec to provide a reliable self-contained test to signal that its binary is, for example, world writable: if it is world writeable a potential attacker can replace the binary and thus fake the test. On the other hand, on Linux systems and most Unix system the setuid-root bit is stripped when the image is rewritten, which largely solves this specific problem. | |
Latest revision as of 13:47, 14 April 2010
To prevent a wrong installation of gLExec, which could lead to easy exploitation of the computer system, an outside 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 but also the file permissions are verified.
Note that it is impossible for gLExec to provide a reliable self-contained test to signal that its binary is, for example, world writable: if it is world writeable a potential attacker can replace the binary and thus fake the test. On the other hand, on Linux systems and most Unix system the setuid-root bit is stripped when the image is rewritten, which largely solves this specific problem.
