On Tue, Sep 30, 2008 at 7:59 PM, Robert Connolly <[EMAIL PROTECTED]> wrote: > 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.
There is the possibility of read-only bind mounts to avoid the copying and prevent apps inside the chroot from writing to whatever may be bind mounted. http://kernelnewbies.org/LinuxChanges#head-3c3e558edfbf5fa26433410b9cb3b9328dc542a5 http://lwn.net/Articles/281157/ > > 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 > > -- > http://linuxfromscratch.org/mailman/listinfo/hlfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page > > -- Kevin Day -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
