Another level

Joey Parrish 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 (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
> <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  
>> 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




More information about the hlfs-dev mailing list