web browser suid [was Preemptive strategies]

Kevin Day thekevinday at gmail.com
Tue Sep 30 18:12:00 PDT 2008

On Tue, Sep 30, 2008 at 7:59 PM, Robert Connolly
<robert at linuxfromscratch.org> 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.


> 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

More information about the hlfs-dev mailing list