Prev: apt-get and aptitude
Next: Fedora 12: Tips for setting up a second monitor?
From: Mark Hobley on 20 Mar 2010 05:08
Artist <artist(a)sj.speakeasy.net> wrote:
> So I want to know how important it is to run a web server in a jail, and
> how prevalent jailing it is.

It depends on which webserver you are running, and how secure your cgi scripts
are. You probably need to do a code audit to determine this at this time.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

From: David Brown on 20 Mar 2010 07:25
Artist wrote:
> I have seen the instructions for running Lighttpd in a chroot jail at:
> http://www.cyberciti.biz/tips/howto-setup-lighttpd-php-mysql-chrooted-jail.html
>
> These instructions involve a lot of copying of binaries to the jail.
> This would mean, I assume, that if I were to execute the:
> apt-get update
> command the binaries in the jail will not be updated and would have to
> follow up with a manual operation or script to update the jail. So is
> there a way to put the server in a chroot jail using apt-get, aptitude
> or synaptic that would include the jail in the update process?
>
> Also it appears that installing a server in a chroot jail is tricky
> given the frustrations this person has with it:
> http://redmine.lighttpd.net/boards/2/topics/2433
> So I want to know how important it is to run a web server in a jail, and
> how prevalent jailing it is.
>

An alternative to a simple chroot jail is to use OpenVZ. Then you have
a separate Linux installation inside a virtual server, but it shares the
same kernel as the host. It's much lighter than a full virtualisation
such as KVM, but stronger and more controllable than a chroot jail. For
example, you can limit the cpu and memory resources of the jail /
virtual server, and you can use standard iptable firewalls to control
traffic into and out of the virtual server. And since you can get shell
access to it from the host, you don't need any working logins from
within the virtual server itself.

Since the virtual server has its own separate file system, you can
install, apt-get, update, etc., as you want independently from the host
(with the only restriction being that they share a kernel). You can
even mix-and-match distros - I have a 64-bit Debian Etch host, with
virtual servers being a mixture of 32-bit and 64-bit Debian Etch and
Lenny. Installation of software is normally exactly the same as if it
were for a simple host.

From: The Natural Philosopher on 20 Mar 2010 08:06
David Brown wrote:
> Artist wrote:
>> I have seen the instructions for running Lighttpd in a chroot jail at:
>> http://www.cyberciti.biz/tips/howto-setup-lighttpd-php-mysql-chrooted-jail.html
>>
>> These instructions involve a lot of copying of binaries to the jail.
>> This would mean, I assume, that if I were to execute the:
>> apt-get update
>> command the binaries in the jail will not be updated and would have to
>> follow up with a manual operation or script to update the jail. So is
>> there a way to put the server in a chroot jail using apt-get, aptitude
>> or synaptic that would include the jail in the update process?
>>
>> Also it appears that installing a server in a chroot jail is tricky
>> given the frustrations this person has with it:
>> http://redmine.lighttpd.net/boards/2/topics/2433
>> So I want to know how important it is to run a web server in a jail,
>> and how prevalent jailing it is.
>>
>
> An alternative to a simple chroot jail is to use OpenVZ. Then you have
> a separate Linux installation inside a virtual server, but it shares the
> same kernel as the host. It's much lighter than a full virtualisation
> such as KVM, but stronger and more controllable than a chroot jail. For
> example, you can limit the cpu and memory resources of the jail /
> virtual server, and you can use standard iptable firewalls to control
> traffic into and out of the virtual server. And since you can get shell
> access to it from the host, you don't need any working logins from
> within the virtual server itself.
>
> Since the virtual server has its own separate file system, you can
> install, apt-get, update, etc., as you want independently from the host
> (with the only restriction being that they share a kernel). You can
> even mix-and-match distros - I have a 64-bit Debian Etch host, with
> virtual servers being a mixture of 32-bit and 64-bit Debian Etch and
> Lenny. Installation of software is normally exactly the same as if it
> were for a simple host.
>
By brother in law, who used to contarct for IBM on very large server
farm implemnations, said that this is the way everyone is going: it
allows less actual tin in te machine rooms...saves power, and every
little tinpot Sysadmin who wants 'His departmental server' running 'his'
apps, can have whatever ghastly OS he wants with whatever security he
thinks he knows how to implement without compromising anyone else.

And IBM apparently supports Linux these days. 90% were linux machines on
IIRC blade servers. Massive RAIDED disks and enormous amounts of RAM and
multicore CPUs, but still cheaper and less power than the equivalent
performance from single machines - most of which were never stretched at
all.





From: Nico Kadel-Garcia on 20 Mar 2010 08:52
On Mar 20, 8:06 am, The Natural Philosopher <t...(a)invalid.invalid>
wrote:
> David Brown wrote:
> > Artist wrote:
> >> I have seen the instructions for running Lighttpd in a chroot jail at:
> >>http://www.cyberciti.biz/tips/howto-setup-lighttpd-php-mysql-chrooted....
>
> >> These instructions involve a lot of copying of binaries to the jail.
> >> This would mean, I assume, that if I were to execute the:
> >> apt-get update
> >> command the binaries in the jail will not be updated and would have to
> >> follow up with a manual operation or script to update the jail. So is
> >> there a way to put the server in a chroot jail using apt-get, aptitude
> >> or synaptic that would include the jail in the update process?
>
> >> Also it appears that installing a server in a chroot jail is tricky
> >> given the frustrations this person has with it:
> >>http://redmine.lighttpd.net/boards/2/topics/2433
> >> So I want to know how important it is to run a web server in a jail,
> >> and how prevalent jailing it is.
>
> > An alternative to a simple chroot jail is to use OpenVZ.  Then you have
> > a separate Linux installation inside a virtual server, but it shares the
> > same kernel as the host.  It's much lighter than a full virtualisation
> > such as KVM, but stronger and more controllable than a chroot jail.  For
> > example, you can limit the cpu and memory resources of the jail /
> > virtual server, and you can use standard iptable firewalls to control
> > traffic into and out of the virtual server.  And since you can get shell
> > access to it from the host, you don't need any working logins from
> > within the virtual server itself.
>
> > Since the virtual server has its own separate file system, you can
> > install, apt-get, update, etc., as you want independently from the host
> > (with the only restriction being that they share a kernel).  You can
> > even mix-and-match distros - I have a 64-bit Debian Etch host, with
> > virtual servers being a mixture of 32-bit and 64-bit Debian Etch and
> > Lenny.  Installation of software is normally exactly the same as if it
> > were for a simple host.
>
> By brother in law, who used to contarct for IBM on very large server
> farm implemnations, said that this is the way everyone is going: it
> allows less actual tin in te machine rooms...saves power, and every
> little tinpot Sysadmin who wants 'His departmental server' running 'his'
> apps, can have whatever ghastly OS he wants with whatever security he
> thinks he knows how to implement without compromising anyone else.
>
> And IBM apparently supports Linux these days. 90% were linux machines on
> IIRC blade servers. Massive RAIDED disks and enormous amounts of RAM and
> multicore CPUs, but still cheaper and less power than the equivalent
> performance from single machines - most of which were never stretched at
> all.

I'm seeing this as well. A chroot jail is basically a cheap way to do
this: by relying on the same kernel, it's theoretically possible to
reach back and gain access to the same hard drives or mount points.
But practically, it's a pretty efficient to share the iron without the
awkwardness of full OS management tools. It's crucial to the "mock"
software package builder, which builds a chroot from scratch for
building RPM's to avoid using your work area or weirdly setup
development areas. Similarly, there are older, full chroot setups for
OpenSSH.

These days, a lot of programs do a very limited chroot or chroot-like
setup to limit access to filesystems. Various FTP applicatons have had
them built in for years, and OpenSSH finely included some limited
chroot functionality for sftp. Unfortunately, Apache doesn't tend to
be one that easily allows a full chroot cage. And casually built PHP
or Perl modules are widely published, widely used, and widely modified
for local usage without proper concern for security. And they can
reach around your local filesystem with whatever privileges the
"Apache" user has. And far too many people rely on firewalls, trust in
their co-workers, and other forms of security that just aren't good
ideas in the real worlds. (Don't get me going on passwords saved in
clear-text by jabber and Subversion, or SSH keys without passwords.)

Getting an application into a chroot cage can be a bit of an adventure.
From: Mark Hobley on 20 Mar 2010 10:08
The Natural Philosopher <tnp(a)invalid.invalid> wrote:
> The SQL isnt directly accessible

> The moment someon fills in a form that invokes server script action, you
> have to ask yourself 'how could this be subverted to do dmage' and if
> you find a way, plug it.

Out of interest, I have a third party package (cvstrac) that has precisely
that problem.

I am going to do a code scan, to locate and remove all of the dangerous
external command invocations.

By mentioning sql though, you have raised a question in my mind. Can sql run
external programs or cause damage outside of the database, or is the
scope for damage by sql limited to the sql database itself?

(In this case the sql engine is sqlite, but I do have packages that use
postgresql and mysql, that also require auditing.)

http://markhobley.yi.org/policy/publicinterface.html#scope

> A chrooted environment seems pointless to me.

Security by design is a good thing, and we should not need the chroot. However
isn't what you get from third party code. A lot of packages need a code audit
at this time.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: apt-get and aptitude
Next: Fedora 12: Tips for setting up a second monitor?