Saturday, October 18, 2014

Firejail: Sandbox individual applications at will on Linux

We take a lot of risks with our computers. Sure, we dutifully apply the latest security patches from our software and operating system vendors but those don't
account for yet undiscovered bugs that may be lurking deep within the heart of some of the most vulnerable software we use. The truth is that, if someone can compromise an Internet facing program on your computer, they basically have the same rights and privileges on your machine that you do and can access all of the files you have access to.

UNIXs and UNIX like operating systems have long had the concept of a 'jail' as a way to sandbox untrusted software away from the rest of the system. But it's generally difficult to set up and consumes a good amount of resources. That type of sandboxing is also best suited for servers and isn't as useful for desktop users.

Enter Firejail

Firejail is a new application sandboxing tool that allows you to quickly and easily set up a jail for any program you don't want to have access to your entire system. Using the concept of setuid, Firejail jails applications so that, if they are compromised, the attacker only has access to a very limited part of your system and is effectively blocked away from all other parts - even the parts that the user running the application has access to.

Firejail is also amazingly easy to use. While you can get a bit complicated with the way you configure the program, you don't have to. For example, running Firefox in its own jail is as simple as typing

firejail firefox

Seriously, that's it. This simple command sets up a jail with default restrictions and then starts the Firefox web browser inside that jail. Of course, the default jail might be too restrictive for some programs so you can customize what each program has access to by creating application profiles.

I've been playing with Firejail for a few weeks now and love it. Sure, it's not a guarantee that someone isn't going to breach your system and wreak havoc. But it's just another layer they have to get to in order to do so and, historically, jails have shown to be pretty secure.

So if you want to bolt one more layer onto your security, check out Firejail and see what you think! it's available for all Linxes and BSD's.

Saturday, September 27, 2014

ShellShock: Another indictment against the "many eyes make all bugs shallow" mantra of Open Source

A few months ago, the Internet was hit by one of the largest security vulnerabilities in its history: a years old bug in the OpenSSL cryptography program called "Heartbleed". The bug allowed any attacker who had the time to attack a server running OpenSSL and retrieve sensitive information like usernames, passwords, and other private information. When discovered, the bug was quickly patched and excuses were made. This was not an indictment of the open source model, advocates argued, but the fact that OpenSSL was underfunded and understaffed.

Earlier this week, another bug called ShellShock surfaced which has the potential to be just as big and destructive as Heartbleed. The bug has to do with the way the popular UNIX/Linux shell called bash processes variables. It allows anyone who knows how to exploit the bug the ability to run arbitrary commands on any server that's vulnerable to the bug. Unfortunately, 'any server' could possibly mean nearly every UNIX/Linux server deployed in the last 20 years.

Read that carefully: the bug is 20+ years old. It came into being in Bash 1.1. And it allows attackers to take over a vulnerable system and do pretty much anything they want with it.

We in the open source world like to tout that our software is secure because the code is available and people can look at it to discover and fix bugs. Popular developer and open source advocate Eric Raymond once said "with many eyes, all bugs are shallow". But we now have two examples in two major and commonly used pieces of software that have somehow missed being found for YEARS and, in one case, nearly TWO DECADES.

While I'm not intimating that these flaws are deliberate, one has to wonder how large flaws in such critical systems could go completely unnoticed for such a long length of time. It smacks of sinister influence by some organization, developer incompetence, or it says that nobody is actually reviewing the code.  If any of those are true, then it means open source is absolutely no less vulnerable to critical holes than its proprietary cousins and that should concern us deeply.

Saturday, June 28, 2014

Learn how to use threads in C#

For some odd reason, the article I wrote about loving C# yesterday sparked a flurry of emails asking me about threading. So I thought I'd write a quick and dirty tutorial on how to write multithreaded applications in C#. It's not going to be enterprise-class software, but it should give you a good enough idea to get you started.

First, what is multithreading?

Multithreading is the process of running multiple instructions on a computer at the exact same time. Today's computers often have 4-8 cores which means you can execute 4-8 instructions at the same time by using multithreading programming concepts.  That often (but not always) means your software will do things faster because it can chew through data and instructions at a more rapid rate that a single threaded application.

How about an example?

The code below is a simple example of how to write a multithreaded application in C#. It's not complex and you should be able to figure it out but we'll walk through it once we're done anyway.

using System;
using System.Threading;

namespace AMulthreadedApplicationExample
{
    class ThreadedProgram
    {
        public static void MyChildThread()
        {
            Console.WriteLine("Hello World from thread #2!");
        }
        
        static void Main(string[] args)
        {
            ThreadStart childthrd = new ThreadStart(MyChildThread);
            Console.WriteLine("Hello World from thread #1!");
            Thread childThread = new Thread(childthrd);
            childThread.Start();
            Console.ReadKey();
        }
    }
}
Much of this code should already be familiar to you as it's all part of a standard C# program. So let's look specifically at the MyChildThread() method and a few statements in the Main() method.

As you can see, the MyChildThread() method is nothing special. It's just a standard method that gives no hint that it's going to be run in a multhreaded way. All the magic happens in the Main() method and it's pretty easy to understand.

First, we define a ThreadStart delegate called 'childthrd' and pass the name of the method we want to execute in the new thread to its constructor. In the third line we actually create the new thread, passing the ThreadStart delegate in the constructor of the new thread. Finally, We execute the new thread with a call to the Thread.Start() method. This last line of code is what actually starts (or schedules to start) the new thread that executes the MyChildThread() method.

Once started, threads usually run to their end and then gracefully die. But there might be times that you want to explicitly kill a thread before it finishes executing. This too is amazingly easy. To kill a thread prior to its completion you simply use the Thread.Abort() method and it kills it. It's that simple. 

While this is not, by any stretch of the imagination, an exhaustive look at threads, it should be enough for you to start doing your own research. Threads are a powerful way to write high performing software and, once you learn them, you'll find all sorts of situations where they come in handy.

Happy multitasking!