From: The Natural Philosopher on
Mark Hobley wrote:
> 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?
>

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.
>
From: Artist on
Grant wrote:

> 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.
From: Artist on
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.
>

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.

--
If you desire to respond directly remove the "sj." from the domain name
part of my email address. It is a spam jammer.
From: Artist on
David Brown wrote:
> 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?

--
If you desire to respond directly remove the "sj." from the domain name
part of my email address. It is a spam jammer.
From: Aragorn on
On Sunday 21 March 2010 01:15 in comp.os.linux.setup, somebody
identifying as Artist wrote...

> David Brown wrote:
>> 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?

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)