[nycbug-talk] Jail Performance

[Isaac Levy]

Wordup Sunny, Pete, All,

On Jan 5, 2005, at 9:25 AM, Sunny Dubey wrote:

> On Tuesday 04 January 2005 22:54, Pete Wright wrote:
>> Hey nycbugers,
>> 	I've been kicking around some ideas regarding jailing
>> in an "enterprise" environment.  While jails do have the obvious
>> benefit of added security; one thing that interests me are the
>> possibilities of using jails to assist with server and app.
>> management in distrubited envrionments.  The basic idea I am
>> thinking of is creating jails for specific applications that
>> get loaded to a farm of servers via PXE-TFTP.  One would netboot
>> a server, and then dist a jail to that system after boot.
>
> I have to admit, I don't see the security behind a single jail 
> solution.  If I
> need to run httpd/maild/something-d whatever I run is going to touch 
> XYZ.
> (In this case XYZ can be sensitive data, databases, etc).  
> Theoretically I
> already have a security issue by running whatever service/daemon/app.
>
> The OS becomes nothing more than a management tool that provides for 
> me to
> admin, provides the computing needed by whatever app, and the OS itself
> becomes a security risk.

This is indeed true for FreeBSD jailing, a Jail Exploit is something 
that any jailing sysadmin should plan for, (but sysadmins should 
likewise have contingency plans in place for SSH or even other serious 
show-stopping OS exploit, for ANY OS).

>   That being said the host-OS must provide for the
> jail-OS which in turn provides for the app.  Each time you add an OS 
> into the
> picture, I would assume it is another security risk.

Well, this model is correct for User Mode Linux, but not for FreeBSD 
Jailing- the Jailed OS's don't even have their own kernels, no direct 
access to memory, and highly restrainable device access.  (Does httpd 
for example need to care about access to dmesg or see all dev nodes?)

It's one of the tradeoffs and things which make FreeBSD Jails a 
virtualization which is sane in contexts where securely isolating 
mutually non-trusted processes is the primary issue at hand, and UML 
jailing sane when one's requirements call for multiple distros of Linux 
to run.

My understanding of Pete's requirements here are that the Jailed 
application be something which run a specific enterprise-level app, or 
suite of apps, and in that context the actual jailed system could be 
stripped down a bit based on the general requirements of the 
application- and the security, stability and performance of the overall 
system would be stripped down to just managing the resources that the 
application requires- a cost effective means to an end if it's managed 
thoughtfully.

>
> (I'm thinking of data security greatly here, heh)
>
>> Seems
>> simple enough...but what about performance.  Has anyone noticed
>> any significant performance bottlenecks w/in jails.  I would not
>> expect any, and have not seen any either.  But maybe there is
>> something I'm missing?
>
> The only bottle-neck would be I/O and physical devices (hard drives).  
> But if
> you are only running one jail, then you have little to worry about.  
> Just
> remember to change the times the daily cron scripts run on the host 
> and jail.
> It can become super painful and ugly when you have multiple 
> cpu/io-intensive
> cron scrips running at the same time, heh

Agreed- that's a really good example of the real performance issues 
when running jailed systems.  Thoughtfully managing complexity...

Rocket-
.ike