From: The Natural Philosopher on 20 Mar 2010 14:55 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 20 Mar 2010 19:30 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 20 Mar 2010 19:50 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 20 Mar 2010 20:15 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 20 Mar 2010 21:25 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)
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: apt-get and aptitude Next: Fedora 12: Tips for setting up a second monitor? |