$arr_19 ), array( 3, false, $arr_20, $arr_24 ), array( 2, false, "\" />", $arr_25 ) ) ); ?> $arr_27 ), array( 3, false, $arr_28, $arr_30 ), array( 2, false, "\" />\n\n", $arr_31 ) ) ); ?> array( 2, false, false, $arr_9 ), array( 4, $arr_10, "if", $arr_245, $arr_248 ), array( 2, false, "\n", $arr_249 ) ) ); ?> rr_466 ), array( 4, $arr_467, "if", $arr_482, $arr_484 ), array( 2, false, "\n", $arr_485 ) ) ); ?> Sandboxing » Linux Magazine
 

Sandboxing

Unknown and Untrusted

If you're like me, you love to test new software, and therein lies one of the huge advantages of the open source world. Almost everything is just a short wget, ./configure; make; make install away, and there's no need to pay, register, provide personal information, wait a week for the CD to arrive, and so forth. But how can you be certain that the software won't interfere with your system, overwrite something, or otherwise behave badly?

Or what if you want to run a web service that you know has a history of problems allowing for remote code execution on the web server?

Sandboxing

A common programming and system administration technique is to use sandboxes, which essentially are restricted areas for the software (or in some cases, an entire operating system or group of systems) to run where it can't interfere with production systems. By setting up a walled-off testing area, you know that if anything does go wrong, it is less likely to cause severe problems, such as affecting your real file server or web server. Additionally, it is easier to observe and verify the behavior of the software because there is less going on within the sandbox.

[...]

Read full article as PDF »

Sandboxing.pdf (812.63 kB)
comments powered by Disqus

Visit Our Shop

Trial Subscription

Digital Subscription

Subscribe

Direct Download

Read full article as PDF »

Sandboxing.pdf (812.63 kB)

Tag Cloud

Bruce Byfield Gnome KDE Kernel Linux Linux Pro Magazine Open Source Projects Red Hat Ubuntu events foss free software google

News