On May 12, 2004, at 10:15 AM, Kirk Strauser wrote:


At 2004-05-12T05:31:41Z, "Chad Leigh -- Shire.Net LLC" <[EMAIL PROTECTED]> writes:

Is there a fundamental problem of having the following all be read-only
file systems, with the noted exceptions?

With the exception of /var (that you mentioned in another post), you should
be fine.

good deal. I have been running test jails like this for a while and it seemed to work.



note that users are not allowed root privilege and hence are not
installing stuff into any of these hierarchies and no /usr/ports

Out of curiosity, what are you using jails for?

Create "virtual servers". Up to now I have been using them as I consolidated real HW onto one more powerful box[1] (since I pay by the rack unit :-), as well as I have a few customers who have their own jails that they run for whatever they want to do. Current production systems are 4.9 (and a 4.7) currently. Currently all jails have their own installs, which is a pita to admin for upgrades. With a single jail install, I can update one instance and restart the jails and get everyone updated. On my test system I am currently using localhost nfs mounting to remount the master jail directories.


I am getting ready to deploy 5.x sometime this summer, hopefully 5.3-RELEASE, and want to virtualize all the users. So each virtual web host (with IP) will actually be running in its own jail, with its own instance of Roxen or apache running (out of one install though). No services except ssh should be running on the main HW, with only admin log-in, no customers, and all mail, web, customer, whatever, services will be running in "hardened" jails (hardened through the read only part).

Additionally, I create file-backed mdXXX file systems and mount them for each jail, so the jail is self contained in its own file system. (And that enforces a quota by default on the user without having to run quota stuff).

The idea is to make it a lot harder for potential hackers to take over the machine. Any cracked web or other services land them in a jail that should be hard to break out of and even harder to take advantage of since the main system directories are read only. I have not been hacked so far anyway, that I can tell (and I do regular checks with various utils), and want to make it that much harder.

best
Chad

[1] we run more than one box but multiples that did not need to be separate have been consolidated down

_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to