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
