Dan Sugalski wrote:
Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
3) Parrot itself (the main executable) has a static, global 1K buffer in it that starts and ends with some recognizable string (like, say, "***+++***START|" and "|END***+++***") so we can find it and overwrite the contents if the library gets moved, for use on platforms where the only way to put a path in is to stick it statically in the executable.
That's pretty disgusting, but I don't know that I have a better idea.
There isn't one, alas, at least for some people.
Everyone running tripwire, et al. (or simply md5sum'ing files to verify integrity) will just love this strategy to death.
It would be no different than what would happen if you had to rebuild to change the built-in path. This just has the advantage of not requiring a compiler, and the source code.
Of course, one can find pathological cases—especially on Unix, which seems designed to thwart this sort of easy-to-administer technology:
• parrot binary unlink'd between exec and main(). (Can't happen on Windows.)
• Launched through a symlink to the binary.
• Launched through a hard link to the binary.
• bin/ is a symlink, so ../share won't work.
• Platform can't find the binary. (Can't happen on Windows, Linux, or Mac OS X.)
• chroot (which, in general, near-the-binary solves rather than complicates).
Pick any strategy, and there will be an opportunity to thwart it. Launch the binary, and then force-unmount the filesystem containing it and all of its resources. That would thwart any strategy with external resources. The point here (which you're probably agreeing with) is to provide a solution that gives people flexibility they can use, not a solution that will work if they are actively trying to trip it up.
As for the security concerns of trusting anything but one's current binary*, parrot could adopt a cryptographic solution for verifying integrity of resource files, if anybody's really all that worried about an errant Unicode character database.
It's really no different that loading an external Perl module today, as I see it.
* - Is the binary itself is really all that trustworthy in the first place? If a user is executing a program through an untrusted or compromised path, they're already putting their life in their hands, and accessing ${bin}/../share won't make the configuration any more trustworthy.
Exactly. The contents of the filesystem are either secure, or they're not.
JEff
