jparrish at layerxtech.com
Tue Dec 8 13:35:16 PST 2009
You can make a pretty simple chroot these days with grsec and a new
kernel (188.8.131.52 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
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
> <robert at 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
>> 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
>> running as the firefox user/group, who has permission on your
>> directory. Other users would not have the ability to do this if
>> 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,
>> ssh)... so it is impossible for one program to get permissions on
>> 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.
>> FAQ: http://www.linuxfromscratch.org/faq/
>> Unsubscribe: See the above information page
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
More information about the hlfs-dev