web browser suid [was Preemptive strategies]

Robert Connolly robert at linuxfromscratch.org
Tue Sep 30 17:59:57 PDT 2008


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20080930/87509380/attachment.sig>


More information about the hlfs-dev mailing list