It would be a very interesting installation. /usr/bin/lynx is an suid script/program which does a chroot to /var/chroot/lynx, drops uid to whichever user ran /usr/bin/lynx, runs /var/chroot/lynx/bin/lynx, which is configured to use a randomly named cache/download directory in /var/chroot/lynx/tmp/downloads/user/, with a read-only-by-owner umask... /var/chroot/lynx/tmp/downloads should have write-only permissions, so one instance of lynx can't get a directory listing of another's, regardless of file permissions. Cache can be shared among different users, if its configured that way, and/or cache can be removed when the program exits. Part of Lynx would be installed in /var/chroot/lynx, like the program and help files... whatever is loadable by the browser, while the other part, like readme files goes in /usr... ./configure might be able to handle this.
I prefer a method of chroot that doesn't involve copying the program and library to the chroot, but instead runs like typical daemons in an empty chroot. Running a web browser with something like Jailkit, or the above example, would allow the user of the browser to start a second instance, with a different config file. If the browser is not copied to the chroot, grsecurity can be configured to only allow users to run programs owned by the admin, and disallow then to run downloaded programs, and thus disallowing them to start a second instance. We would also need to run around finding copies of updated libraries and programs which are in different chroots, unless we use hardlinks.. but this is a problem with different mount points. I gotta say, running Lynx as a shared object while disallowing text relocations in the kernel, with aslr, compiled with stack protection, run time buffer checking, pointer checking with libmudflap, on a system that only allows users to run files owned by the admin, in an empty change-root jail possibly mounted as an encrypted loop offset, with a random key, to enforce storage use, all enforced by access controls, would be stunning. The same could be done with irc clients. The only way I can think of topping this is with my idea to setup a decoy system, with a plausibly deniable encrypted system in the decoy free space (aes converted to base64, so it doesn't make any sense if it's read raw). robert
pgpMgfU2PKKgA.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
