Another level

robert baker robertmbaker at
Tue Dec 8 13:19:25 PST 2009

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> 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
> --
> FAQ:
> Unsubscribe: See the above information page

More information about the hlfs-dev mailing list