Date: Thu, 22 Sep 2005 18:56:37 -0600 From: "Chad Leigh -- Shire.Net LLC" <chad@shire.net> To: f-q questions <freebsd-questions@freebsd.org> Cc: Frank.Mueller@emendis.de, =?ISO-8859-1?Q?Malachi_de_=C6lfweald?= <malachid@gmail.com> Subject: Re: Requesting advice on Jail technique. Message-ID: <2824270F-A826-43F5-A730-00AF3B7B3E2B@shire.net> In-Reply-To: <c090347a05092217516ce9506d@mail.gmail.com> References: <4326D764.1040402@xianshi.org> <4326DC58.1090806@emendis.de> <c090347a05092217516ce9506d@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 22, 2005, at 6:51 PM, Malachi de =C6lfweald wrote: > I am thinking at this point what I am going to try to do is build a =20= > jail > skeleton, then use unionfs to mount on top of that... so in theory, =20= > I could > save a LOT of space while at the same time giving them pretty =20 > complete jails > (one per domain). > Malachi What I did was set up a master jail (that is never actually booted) =20 and use nullfs to mount pieces of that inside each separate jail =20 (mostly read only as well, which provides some security as well as =20 hacked jails cannot have their system executables changed since they =20 reside in a read only space). I did not use unionfs. I have one =20 submaster jail which has a writable /usr with a nullfs mounty (was =20 using localhost nfs before that) so I can install new stuff inside of =20= that. Here is an example /dev/md1910 on /local/jails/intentcenter (ufs, local, synchronous, =20 soft-updates) /local/jails/master/bin on /local/jails/intentcenter/bin (nullfs, =20 local, read-only) /local/jails/master/lib on /local/jails/intentcenter/lib (nullfs, =20 local, read-only) /local/jails/master/libexec on /local/jails/intentcenter/libexec =20 (nullfs, local, read-only) /local/jails/master/sbin on /local/jails/intentcenter/sbin (nullfs, =20 local, read-only) /local/jails/master/usr on /local/jails/intentcenter/usr (nullfs, =20 local, read-only) procfs on /local/jails/intentcenter/proc (procfs, local) devfs on /local/jails/intentcenter/dev (devfs, local) (continued below) > > On 9/13/05, Frank Mueller - emendis GmbH =20 > <Frank.Mueller@emendis.de> wrote: > >> >> Hi there, >> >> if you have enough system resources I would recommend using seperate >> jails for every user. >> All u have to keep in mind is that you won't be able to provide some >> services (SMTP, POP, IMAP, usw.) more than once for the whole system >> because they need a predefined port (25, 110, 443, usw.). Sure you can. Each separate IP, and each jail has its own IP, has =20 its own set of ports. I run a single server with 40 jails and they =20 have their own imap, smtp, etc in each (as required --- most don't as =20= it is not required but it works fine) without any port forwarding or =20 any funny games. >> Some other services, like ssh u can manage through port =20 >> forwarding, http >> through virtual hosting, etc. see above -- all my jails (almost) all have their own apache running =20 inside) >> Separate jails make it much easier to keep track of activities. yes Chad >> It all depends on what applications the user should be able to use. >> >> Greetz, >> >> Ice >> >> Elliot Crosby-McCullough schrieb: >> >>> Dear all, >>> >>> I will shortly be creating a public service on a private box that >>> will include shell access to untrusted users and would like your =20 >>> opinion >>> on the best way to go about this. >>> >>> Obviously jails are a good start, but my main concern is whether to >>> go for one large jail for all the restricted users or one small =20 >>> jail per >>> user. >>> >>> I do not have a wealth of real IPs at my disposal but accountability >>> and security is paramount, therefore I would like to use local IPs >>> through NAT (within the one box) whilst retaining the translation =20= >>> logs. >>> I would like to use one local IP per user in order to keep track of >>> activity. I can afford a few real IPs for the purpose. >>> >>> The accounts themselves will be supremely limited. No root access, >>> just basics such as ssh, perhaps telnet, mutt etc. I do not want the >>> users to have the ability to run any scripts, so perl etc is out, =20= >>> but I >>> suppose the NAT firewall will be a fallback if any compiled =20 >>> programs are >>> uploaded. >>> >>> Each user account is likely to have email/gpg etc but I'm happy to >>> control that from the host system with virtual users and simply =20 >>> deliver >>> into the jail. It is not necessary for the jails to run any =20 >>> services, >>> except the ability to SSH in. >>> >>> As you can see there are factors pulling in both directions, what >>> would you recommend as the best direction to go? >>> >>> Sincerely, >>> Elliot Crosby-McCullough >>> _______________________________________________ >>> freebsd-questions@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >>> To unsubscribe, send any mail to >>> "freebsd-questions-unsubscribe@freebsd.org" >>> >> >> -- >> Frank Mueller >> eMail: Frank.Mueller@emendis.de >> Mobil: +49.177.6858655 >> Fax: +49.951.3039342 >> >> emendis GmbH >> Hofmannstr. 89, 91052 Erlangen, Germany >> Fon: +49.9131.817361 >> Fax: +49.9131.817386 >> >> Geschaeftsfuehrer: Gunter Kroeber, Volker Wiesinger >> Sitz Erlangen, Amtsgericht Fuerth HRB 10116 >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to " >> freebsd-questions-unsubscribe@freebsd.org" >> >> > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-=20 > unsubscribe@freebsd.org" > --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad@shire.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2824270F-A826-43F5-A730-00AF3B7B3E2B>