Running Web Servers In A Chroot Jail
Artist
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.
--
To reply directly remove the sj. from my email address. This is a spam
jammer.
Grant
I don't bother with a jail. Don't run PHP and friends as it is a security
risk. A web server with sane permissions and no upload facility is fairly
safe. Here I block all but GET and HEAD requests. Also not accept requests
to server's IP number, only respond to expected virtual domains.
Problem these days is people use templates and packages that they source
from the big bad Internet -- then blindly put up stuff without any security
audit.
Grant.
Artist
One of my sites will require the ability for members to upload image files.
What is meant by "PHP and friends" ?
Artist
My sites will be run by the Drupal CMS. PHP is required for that.
The Natural Philosopher
are often the problem.
One because they are popular, and therefore worth attacking in the same
way M$ is, and two because they are used by people who understand just
enough to get them working, but not always enough to get them working
PROPERLY and SECURELY.
Mark Hobley
> 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/
Grant
>Artist <art...@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.
Trouble is, how does a newbie know quality from crap information?
I think they're aware of security as an abstract notion, but until
their site gets hacked they don't really focus on the details.
PHP is convenient, but it allows laziness and thus tends to encourage
security breaches.
Running a server in a chroot jail seems like damage containment rather
than prevention, no?
I run http and ftp servers here, both are secure and neither offer any
user/pass logins. Glancing through the logs can be an education.
Grant.
The Natural Philosopher
I run PHP. user/pass combos and not ssh connections. Plenty of attempts
to subvert via what look like hacker bots, BUT no successful ones in 4
years.
Mostly people look for stupidity, like management scripts left open.
The SQL isnt directly accessible, it needs the PHP programs to get at it
from HTTP, and the php scripts aren't accessible, because the setup is
clean, and in nay case they don't allow unlimited access to anything.
There is no FTP access on one machine, the other is tied to my IP
address only, and is password protected.
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.
Ther is no magic solution.
A chrooted environment seems pointless to me. The whole server should be
backed up, if there is damage, replace the server and plug the hole.
What's on the rest of te server of any interest anyyway?
Only time I ever did that was when we set up a public anonymous FTP
service. Which lasted precisely two weeks, not because it was hacked,
but because it became the default dump for a load of ripped off
software. End of our public spiritedness.
David Brown
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.
The Natural Philosopher
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.
Nico Kadel-Garcia
wrote:
> David Brown wrote:
> > Artist wrote:
> >> I have seen the instructions for running Lighttpd in a chroot jail at:
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.
Mark Hobley
> 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
Grant
>Grant wrote:
>> On Sat, 20 Mar 2010 09:08:03 GMT, markh...@hotpop.donottypethisbit.com (Mark Hobley) wrote:
>>
>>> Artist <art...@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.
>>
>> Trouble is, how does a newbie know quality from crap information?
>>
>> I think they're aware of security as an abstract notion, but until
>> their site gets hacked they don't really focus on the details.
>>
>> PHP is convenient, but it allows laziness and thus tends to encourage
>> security breaches.
>>
>> Running a server in a chroot jail seems like damage containment rather
>> than prevention, no?
>>
>> I run http and ftp servers here, both are secure and neither offer any
>> user/pass logins. Glancing through the logs can be an education.
>>
>> Grant.
>
>I run PHP. user/pass combos and not ssh connections. Plenty of attempts
>to subvert via what look like hacker bots, BUT no successful ones in 4
>years.
>
>Mostly people look for stupidity, like management scripts left open.
Yes, and also they try to go above the web root directory to access host
filesystem or find common management directories.
I haven't used CMS (I learned web engineering back when perl and
javascript seemed the only options) so no idea why it is so common to
see news of sites being hacked these days.
>
>The SQL isnt directly accessible, it needs the PHP programs to get at it
>from HTTP, and the php scripts aren't accessible, because the setup is
>clean, and in nay case they don't allow unlimited access to anything.
>There is no FTP access on one machine, the other is tied to my IP
>address only, and is password protected.
>
>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.
Yes. Security is about possibilities, not probabilities.
>Ther is no magic solution.
>
>A chrooted environment seems pointless to me. The whole server should be
>backed up, if there is damage, replace the server and plug the hole.
>What's on the rest of te server of any interest anyyway?
Dunno, I'm not motivated to wear the dark hat ;)
>
>Only time I ever did that was when we set up a public anonymous FTP
>service. Which lasted precisely two weeks, not because it was hacked,
>but because it became the default dump for a load of ripped off
>software. End of our public spiritedness.
Yes, it can be done though. Allow uploads into a write-only directory,
but that then requires operator intervention to vet and transfer files
to a readable area.
Grant.
The Natural Philosopher
> The Natural Philosopher <t...@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?
>
Once you contact the daemon, only the database.
Its conceivable that the e.g. PHP API might be subverted, but I know of
no recorded instance.
> (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.
>
From a security point of view any third party code represents something
whose quality is to an extent unknown, and a target for malice, that is.
Really critical apps have been known to write their own operating
systems, for that reason ;-)
> Mark.
>
The Natural Philosopher
we just made it password only for our customers only,upload wise. And
monitored usage and killed anything that was illegal and closed down the
account.
But I don't remember it being a problem once it was restricted to
customers only.
Its a long time ago now. 1997?
something like that.
> Grant.
Artist
> Running a server in a chroot jail seems like damage containment rather
> than prevention, no?
>
Yes it is. I consider it just one line of defense.
--
If you desire to respond directly remove the "sj." from the domain name
part of my email address. It is a spam jammer.
Artist
Thanks for the tip on OpenVZ. I have an interest in it. Unfortunately I
have Debian Lenny. The only distro I see for Debian at:
http://download.openvz.org/debian/dists/
is for Etch.
Artist
> Artist wrote:
> 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.
>
What I have is a XenServer based VPS account at a web host. This would
mean running a VS inside a VPS. Is that possible, practical and desirable?
Aragorn
identifying as Artist wrote...
Since OpenVZ does itself not use any hardware virtualization extensions
for the operating system level virtualization layer, it is capable of
running on top of Xen. This should include XenServer.
On the other hand, for such a set-up, it is advisable to use one of
the "stable" OpenVZ kernels such as 2.6.26 or 2.6.27 instead of the
default 2.6.18 kernel and configure and compile it yourself from
sources, so you can make it paravirtualized. Works much more
efficiently than a stock OpenVZ kernel, which requires that the
hardware does have virtualization extensions enabled, since the default
OpenVZ kernel (2.6.18) does not have in-kernel Xen support yet while
all post-2.6.23 kernels do[1], but it might not be enabled in the
binary kernel package.
[1] Xen domU support was added to the upstream vanilla kernel in 2.6.23
but was at that stage still largely defunct for 64-bit and/or SMP
guest systems.
--
*Aragorn*
(registered GNU/Linux user #223157)
Artist
The Debian Lenny I have is 32 bit.
David Brown
Lenny has OpenVZ support itself, so there is no need for the extra
repository from openvz.org:
<http://www.howtoforge.com/installing-and-using-openvz-on-debian-lenny-amd64>
Also look at <http://wiki.openvz.org/Installation_on_Debian>
<http://download.openvz.org/debian-systs/> has some newer versions of
the tools than Lenny, if you are looking for the latest and greatest
rather than the stablest.
The Natural Philosopher
> 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 particular the ability of SQL to invoke other programs is now limited
by design to 'safe spaces' directories. E.g. there is an 'INTO OUTFILE'
command that will let you dump data into a (text/CSV) file, but latest
iterations have constrained this to be inside of the Var/Lib/Myslql tree
IIRC. By default anyway.
In short in order to dump data to an external file, (or read it from an
uploaded file) the user that e.g,. the web server is using to connect to
mysql, must have file privileges...you normally don't do this...even for
uploaded files, it is better to turn them into hexadecimal and INSERT
them in the database that way rather than use LOAD DATA.
So that's one layer of protection. The other is that you can 'set
secure_file_priv'
"this variable is used to limit the effect of data import and export
operations, such as those performed by the LOAD DATA and SELECT ... INTO
OUTFILE statements and the LOAD_FILE() function. These operations are
permitted only to users who have the FILE privilege.
secure_file_priv may be set as follows:
If empty, the variable has no effect. This is not a secure setting.
If set to the name of a directory, the server limits import and
export operations to work only with files in that directory. The
directory must exist; the server does not create it.
If set to NULL, the server disables import and export operations.
The default value is platform specific "
> (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.
>
I tend not to use presupplied tools on websites as far as possible. If
you use a tool you do not understand and have not written, you cannot
protect against bugs in it.
Its bad enough e.g. discovering the PHP often does not work as
adverstised, run out of memory when its should have lots, and so on.
These days the moment one of these turns up I grab the C compiler.
> Mark.
--
"An intellectual is a person knowledgeable in one field who speaks out
only in others...”
Tom Wolfe