You can make a pretty simple chroot these days with grsec and a new kernel (2.6.27.10 or newer). With grsec, you can secure jails with all kinds of limitations that prevent most every break-out method. And with a new kernel, you can create a read-only bind mount.
So you can create a jail with only the things firefox needs to write to (/home), then "mount --bind -o ro" the /bin, /usr, /lib, /etc, and so on. Under no circumstances can firefox write to those read-only mounts (even as root) and grsec prevents jailbreaking even with a populated /dev, /proc, and /sys. Need to upgrade a library? It only lives in one place, not in every jail separately. And each jail has a full view of the filesystem. (Unless you choose to, say, not bind in a copy of /usr, or whatever. If you had some compelling reason, you could design a jail to be missing some folder from the outside.) And you don't have to rely on a union fs to get this full view, which makes it simpler to setup and maintain. --Joey Parrish On Dec 8, 2009, at 3:19 PM, robert baker wrote: > Two thoughts on this. > > 1. If it doesn't require a whole lot of time to get firefox in a > chroot. For example you aren't required to copy a ton of libs into the > chroot or statically compile the binary or anything else that takes > poking and prodding. This idea sounds like a nice upgrade in security. > > 2. I discussed feature creep with you a while back on irc. I know I > don't have too much room to talk since I keep disapearing (Work, > school, and personal life are dominating me for the time being.) but > at some point if the project is going to have a chance at attracting > contributors and testers there needs to be a clear well oriented goal. > Adding features can stear the project away from that goal. While I > beleive that these features are worth the effort, at some level, I > still think narrowing the scope to get a reign on the project is the > best path to take for the moment. > > Having said both of those two bits I will admit that securing browsers > is paramount. I am all for shackling firefox into a jail if the work > is not greater than the reward. > > On Mon, Dec 7, 2009 at 11:52 PM, Robert Connolly > <rob...@linuxfromscratch.org> wrote: >> I want to brainstorm something I brought up before. >> >> The firefox (or irssi, or even ssh client) program could be run as >> another >> user/group (suid/sgid), so that it does not have permission to >> read/write/execute files it does not need. So it has less than your >> permissions. But, under this design firefox would be able to write >> to other >> user's cache. What is the way around this problem? >> >> chroot might be of help. The firefox client could chroot to >> ~/.firefox, >> running as the firefox user/group, who has permission on your >> ~/.firefox >> directory. Other users would not have the ability to do this if >> they're >> confined to this /usr/bin/ssh script. >> >> Making /usr/bin/ssh a script to use suid myusername-suid, is >> another idea, so >> that system users do not reuse the same user for firefox (or irssi, >> or >> ssh)... so it is impossible for one program to get permissions on >> another. >> The number of usernames in /etc/password skyrockets with this >> though... with >> one new user for each application, multiplied by each user. >> >> Access control lists can also control this, but I am looking for >> another level >> to create a redundancy. >> >> robert >> >> -- >> http://linuxfromscratch.org/mailman/listinfo/hlfs-dev >> FAQ: http://www.linuxfromscratch.org/faq/ >> Unsubscribe: See the above information page >> >> > -- > http://linuxfromscratch.org/mailman/listinfo/hlfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
