web browser suid [was Preemptive strategies]
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
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the hlfs-dev