web browser suid [was Preemptive strategies]

Robert Connolly robert at linuxfromscratch.org
Tue Sep 30 19:59:56 PDT 2008

The runas program, I think Debain wrote it, is a leaner alternative maybe. 
From what I understand from the manual page, an suid user 'lynx' script could 
run runas, where runas is suid root but only executable by the runas group, 
which lynx is a member of... and the runas program will start lynx, chroot to 
an empty directory, and change uid to the lynx user.

It's dangerous to have runas suid root, but maybe libcap could reduce it to 
only having chroot capabilities.


On Tuesday September 30 2008 09:48:07 pm Robert Connolly wrote:
> On Tuesday September 30 2008 09:12:00 pm Kevin Day wrote:
> > 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-3c3e558edfbf5fa26433410b9cb3b9
> >32 8dc542a5 http://lwn.net/Articles/281157/
> I just tried to bind mount /lib and /usr/lib to /tmp/bind-test, and
> /usr/lib replaces the /lib mount, instead of adding to it.
> It may work with something like mounting /opt/lynx2.8.6rel.5
> to /var/chroot/lynx, where Lynx was installed with
> DESTDIR=/opt/lynx2.8.6rel.5, so that /opt/lynx2.8.6rel.5/usr/bin/lynx
> exists, and then /lib can be mounted to /var/chroot/lynx/lib.
> This gets around the problem when upgrading dependency libraries, but it
> adds more files to the chroot than we need. It's not that bad though. It's
> not flexable enough to work with any package, but I can't think of any
> package that can use a chroot like this that it wouldn't work with.
> Bind mounting single files would be nice (a hard link across mount points),
> but it would make a serious mess out of /proc/mounts.
> 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/9a5fb62a/attachment.sig>

More information about the hlfs-dev mailing list