Posts Tagged ‘Security’

This past week I had a very stimulating discussion with a very talented co-worker of mine. This discussion was about Exec-Shield (DEP for all my Windows fans) and ASLR under RedHat. Through the course of this discussion, we discovered a very interesting script that helped us detect which of our running processes were protected by exec-shield as well as some nifty kernel tunables for exec-shield, and ASLR. Incidentally, he wrote a very informative article about it over at, you should check it out. Also he has a lot of other great nix sysadmin stuff there that is definitely worth your time.

Now you’re probably thinking. Hey DT what’s this got to do with Ubuntu, you’re talking about RedHat, what’s with the sensational title?

To that, I say. “Dear reader, you catch on fast. It has absolutely NOTHING to do with Ubuntu.” Therein lies our problem, for a server OS that Canonical touts as production ready with nifty slogans like “We are cloud.” I was somewhat astonished to find that exec-shield support in Ubuntu is rather limited (read nonexistant).

What is this exec-shield and why do I want it?

Exec-Shield also referred to as NX bit and DEP is a system designed for 64 Bit PAE (Physical Address Extension) systems to divide executable code into two sections, a .data section and the actual executable instructions. Basically this helps you mitigate stack, heap and int based overflows by mitigating the executability (is that a word?) of injected shell code. The overflow will still happen, however no payload execution happens. This is obviously a nice thing to have happening.

How do I know it’s enabled?

Well quite simply on a RHEL/CentOS/FC box if you do the following

sudo sysctl kernel.exec-shield

You will get some output that signifies what setting you have for exec-shield. Default is 1

kernel.exec-shield = 1

It should look like that. Really quick, a rundown on the possible values.

  • 0 – Disabled, regardless of whether the application is compiled to support it.
  • 1 – Enabled if the application is compiled to support it.
  • 2 – Enabled for all applications unless they are compiled without it.
  • 3 – Enabled regardless of what the application is compiled to support.

But what about Ubuntu? If you were following along with Ubuntu you likely got an error when you typed that command. Why is that you ask? Quite simply, your kernel does not support Exec-Shield.

Time to switch to RHEL?

Ideally, for production systems yes, for many reasons not just this, but it’s expensive (CentOS isn’t ;-)). That being said you know I love Ubuntu. So, I have an alternative solution for you.

Emulating Exec-Shield on Ubuntu

There are a couple of things to understand here before we start. Debian upstream and thus Ubuntu removed the exec-shield patch from the distribution a few years ago, claiming it was replaced by gcc’s compile time optimizations. There is a major flaw in this logic, these enforcements are made at the application level, which is a terrible place to have them made. The kernel level is much more suitable for this type of control. Incidentally, the two work wonderfully together.

We do not have access to exec-shield, however we can emulate it through grsec, which is exactly what we are going to be doing here.

Note : this involves recompiling your kernel, so breakage could ensue.

Note+ : You will also need build essential for this

sudo apt-get install build essential

Note++ : For make menuconfig we’ll also need ncurses-dev.

sudo apt-get install libncurses5-dev

Step 1 : Downloading grsec

The first step is to obtain the latest stable release of grsec.


Step 2 : Downloading Kernel Source

Next we need the kernel source, this has to be done with an unpatched kernel so we can not use our existing kernel source.


Once it’s downloaded extract your kernel source

tar xzvf linux-

Step 3 : Patching the kernel

Now we’ll patch our kernel source.

cd linux-
sudo su -
patch -p1 < ../grsecurity-2.2.2-

Step 4 : Configuring our patched Kernel

Now we run

make menuconfig

Most of the defaults are acceptable however we need to look at our “Security” Options








The first thing we’ll look at is GRSecurity. There are a variety of options in here. You will need to explore the ones that fit your needs best. However I recommend enabling the following

  • Security Level High
  • Hide /proc from users
  • Sysctl Support On
  • Enable Features by default On

There are many more tunables that you can fiddle with here.

There are also quite a few tunables under PaX that can be adjusted here however, the defaults are quite acceptable.








Once you’re done making changes we’re ready to compile the kernel.

Step 5 : Compiling our Grsecurity Kernel

For non-Ubuntu distros (since this has been pretty generic up until this point) we can simply


Alternatively for Ubuntu users we can build our kernel in the Debian method by doing the following.

make-kpkg clean
sed -rie 's/echo "\+"/#echo "\+"/' scripts/setlocalversion
rm localversion-grsec
fakeroot make-kpkg --initrd kernel_image kernel_headers

Note : If you follow this step you may simply use dpkg -i to install your new kernel. Users following the other method should update their grub config and install the kernel in the normal method.

After Kernel Installation

Once we have our GRSecurity enabled kernel installed we can use the gradmn tool to put GRSecurity in learning mode and create a policy which will be enforced.
You can learn more about doing that here.
Once you have done this your Ubuntu server will be much more ready for production usage. Though…Installing CentOS takes far less time 😉


So you utilize public wifi a lot, or maybe you share an internet connection in a dorm with a creepy Comp Sci major who wants nothing more than to talk to your girlfriend on Facebook. The problem is he wants to do it while impersonating you. Man in the Middle attacks are ever so common on shared internet connections these days. They make it extremely easy to hijack credentials, and analyze other packet traffic, even if you’re using SSL. Tools like SSL strip, Wireshark and Ettercap make it alarmingly easy to take apart SSL.

Now — we know (or might not) that SSL is still reasonably secure, there aren’t really any inline attacks for breaking SSL. BEAST not withstanding which still can’t break SSL at line speed, SSL isn’t actually being broken. What is happening is network traffic is being manipulated, usually via ARP poisoning and use of a proxy such as SSLstrip to downgrade the connection and fake SSL authentication when in reality, it’s not happening. That being said, anyone on a shared network segment can rather easily acquire your credentials.

What we’re going to discuss is using Wireshark to detect the most common type of MITM attack. Note this is performed on Ubuntu 11.10 with Wireshark, if you don’t have Wireshark you can get it by doing the following.

sudo apt-get install wireshark

and starting it doing this

gksudo wireshark &

By far ARP poisoning attacks are the most popular, they are extremely easy to do, in fact it’s beginning to seem like every 15 year old has a Youtube video demonstrating how to grab Facebook credentials using Ettercap. In conjunction with SSLstrip this can be devestating. The most common and effective method of doing this on a shared network segment is to ARP poison the target router, or entire subnet. This also makes it extremely easy to detect. Because an ARP poisoning attack works by repeatedly Re-ARPing the target it will occassionally collide with ARP frames sent by the ACTUAL host. We can detect this with Wireshark by filtering duplicate address ARP frames.

We simply start our capture and set our filter to “arp.duplicate-address-frame” When we examine the data provided by Wireshark we also see that the IP address is being claimed by another MAC address. Under normal network operations two systems should not be claiming the same address on the same network segment, particularly the address of the gateway.

Sure. You’re thinking what about other attacks like DHCP spoofing or ICMP Redirects, well here’s the thing, those are not full duplex attacks and pose little to no threat to an SSL connection. For instance if an attacker wants to create a DNS redirect scenario ARP poisoning would be much easier and more effective on a switched or broadcast based network than ICMP redirect based attacks which will fail on a switched network.

Oh by the way happy Thanksgiving for those of you in the states 🙂

Lately there has been a lot of hullabaloo about the Ubuntu Guest Account seen in Oneiric, though it’s been around for a while the feature has become much more visible. As such it has a lot of people having bad flashbacks from the Windows NT series Guest account. An interesting article written by Dan Dieterle at Cyber Arms addresses some of those concerns, and makes a valid point regarding a Social Engineering attack or some form of remote browser exploit.

The article warns users that a guest user could become the victim of a social engineering attack that leads to remote compromise, also scary is the fact that Firefox 7.0.1 POC exploit code has recently been released into the public that allows for remote compromise of the browser. What we’re going to explore here is, in the event this happens. What protections do this account offer, and is it in fact a security liability. The Guest Session account in case you do not know, does not require a password to access. For this discussion we will be using the Social Engineering Toolkit Java Applet vector that was discussed in Dan’s article, though it’s important to know a remote shell is a remote shell. For the “victim” machine we will have a fully patched Ubuntu 11.10 install , with a default configuration of UFW enabled. I’m not going to bother with AV for two reasons. One AV on Linux sucks (particularly the free products) and two our shell will never hit the hard drive so there is really nothing for AV to find here

Our Shell

As I pointed out in the discussion on Dan’s blog, the shell we get here would be extremely neutered, and as we can see it is. Guest really doesn’t have a whole lot of permissions to do much of anything. However Dan’s counter argument was that the shell could be used to profile the system, an argument that in this case is quite valid.

If you click this you're pretty much dumb...Let's click it 😛

oh look another shell 🙂

Well that's fancy lol.

We were able to gather the usernames for the system. This could be valuable to a remote attacker in the event that you are one of those Ubuntu fans who like to run SSH on their home system to administer it from work. However, what if they aren’t running any services and this is just a typical desktop installation?

So the question is can we break out of this shell and do something more malicious? Sadly not really, As I stated in my discussion over on Cyber Arms there are a variety of security features locking this account down.

What Security Features?

Don’t let the lack of a password on this account fool you. It’s locked down pretty tight. The Guest Session is confined with mandatory access controls in the form of Apparmor. There are two things someone who is trying to compromise a system running no services doesn’t want you to have, NoScript and Mandatory Access Controls. In this case we don’t have No Script installed, and if the user was silly enough to click our Java Applet warning despite the gigantic Security advisory posted all over it Apparmor will confine the disaster to being almost fruitless.

If we examine the apparmor profile (which can be found in /etc/apparmor.d/lightdm-guest-session). We will see the following.

# vim:syntax=apparmor
# Profile for restricting lightdm guest session
# Author: Martin Pitt


/usr/lib/lightdm/lightdm-guest-session-wrapper {
/etc/compizconfig/config rw, # bug in compiz

/ r,
/bin/ rmix,
/bin/fusermount Px,
/bin/** rmix,
/cdrom/ rmix,
/cdrom/** rmix,
/dev/ r,
/dev/** rmw, # audio devices etc.
owner /dev/shm/** rmw,
/etc/ r,
/etc/** rmk,
/etc/gdm/Xsession ix,
/lib/ r,
/lib/** rmixk,
/lib32/ r,
/lib32/** rmixk,
/lib64/ r,
/lib64/** rmixk,
/media/ r,
/media/** rmwlixk, # we want access to USB sticks and the like
/opt/ r,
/opt/** rmixk,
@{PROC}/ r,
@{PROC}/* rm,
@{PROC}/asound rm,
@{PROC}/asound/** rm,
@{PROC}/ati rm,
@{PROC}/ati/** rm,
owner @{PROC}/** rm,
# needed for gnome-keyring-daemon
@{PROC}/*/status r,
/sbin/ r,
/sbin/** rmixk,
/sys/ r,
/sys/** rm,
/tmp/ rw,
owner /tmp/** rwlkmix,
/usr/ r,
/usr/** rmixk,
/var/ r,
/var/** rmixk,
/var/guest-data/** rw, # allow to store files permanently
/var/tmp/ rw,
owner /var/tmp/** rwlkm,
/{,var/}run/ r,
# necessary for writing to sockets, etc.
/{,var/}run/** rmkix,
/{,var/}run/shm/** wl,

capability ipc_lock,

# silence warnings for stuff that we really don’t want to grant
deny capability dac_override,
deny capability dac_read_search,
#deny /etc/** w, # re-enable once LP#697678 is fixed
deny /usr/** w,
deny /var/crash/ w,

Now, if you don’t understand Apparmor profiles, I’ll basically sum this up — This profile does not allow you access to much of anything that allows an attacker to escalate out of the guest session. There are a few caveats to that which I will discuss in a moment.

In addition to the mandatory access controls in place via Apparmor we have a well tuned discretionary access control system (permissions) in place that keeps us out of most places we should not be.

As a matter of fact, I could not find a single flaw in the implementation of the guest session save for one.

Why In Heaven’s Name Would Guest Need GCC?

This was the one issue that I saw for some reason unknown to me, the Guest Session is given access to a compiler. This is generally bad stuff. If one can compile source code, and execute it. There is a chance that escalation can take place. This would require a vulnerability in another application and or the Kernel itself. If this were present it could be exploited to allow root access bypassing even Apparmor. That being said, we can use Apparmor to nip that in the bud really quickly.

Simply add the following lines to your apparmor profile

deny /usr/bin/gcc rw,
deny /usr/bin/gcc-4.6 rw,

Since the author of that profile was so kind as to comment on this blog post I figured I would add this bit in. As Martin pointed out this does NOT prevent someone from downloading GCC to the guest session and running it from a different path. Nor does it prevent an attacker from utilizing Perl,Python, or whatever else might be installed. (remember how we got here was Java).

As I reflected on Martin’s comment I feel this is probably an irrellevant measure (this is what I get for writing this stuff at 1 AM).


Honestly, I would say the Guest session is rather well secured, however you can always edit the MAC in place to lock it down further. Or as Dan Dieterle mentioned in his article disable the account functionality alltogether. If you’d like to know how to do that read his article he explains it, it is linked at the top of this one.


Also for those of you who use SET frequently, and or are experimenting with the Java Applet Attack Vector under Linux, you might consider upgrading the shell you are provided by default to meterpreter instead of the linux default reverse shell. If you wish to do this simply run the following (this is under Back Track 5 R1, your path may vary.)

sed -i 's:linux/x86/shell/reverse_tcp:linux/x86/meterpreter/reverse_tcp:' /pentest/exploits/set/src/core/payloadgen/

This will give you a meterpreter shell by default instead of linux/x86/shell/reverse_tcp. You can substituate linux/x86/meterpreter/reverse_tcp for any other payload you’d like as well, including a custom payload.

Special Thanks also go to Martin Pitt for his comment that shed some light on the MAC in place for the lightdm-guest-session.

I was considering posting some relatively technical article tonight, in fact I laid the ground work, fired up the VM did all the testing and took all the screen shots already. However, in doing that I realized that quite frankly many of the individuals in the open source community who put forth an effort to aid, educate or in other words help new users understand the security benefits and ramifications of a Linux based operating system are rarely praised.

Sure there are professionals out there, and we seek to educate, others just want to make it through the day alive, and others still are security evangelists (divas); a title which I myself have no doubt earned several times over in certain circles. The truth is though, particularly in the community on Ubuntu Forums the individuals who try to help are not compensated in any way shape or form. They are volunteering, and they do it for the betterment of the community. I am speaking about several individuals in particular whom I will name (well handle) at the end of this. These individuals took a concept, that is not easy to approach “Security for Newbies” (new users being the politically correct term), and undertook a huge task by organizing the community and putting out a fairly detailed amount of documentation as well as a gigantic thread with all sorts of crazy stuff in it. They did this in a relatively limited time and with a limited knowledge base, researching a lot of information so that others may learn from their work.

I was involved in this project as well, and while I did not even begin to bear the burden of the work, I did receive a portion of the flames that I’m sure those spearheading the project received. I heard “hey man Ubuntu is secure, you’re spreading fear uncertainty and doubt.” or “This isn’t what Open Source software is about”. Truthfully, with respect to those opinions (it’s my blog if you don’t like it leave) I disagree. The efforts put forth by these individuals is at the very core of OSS, in that they are sharing the knowledge which they acquired, whether you like it or not for your benefit. Of course, if you disagree, or just don’t want to hear it, you’re entitled to that opinion.

However, my thoughts on the subject are that everyone involved did an amazing job, and it was a great project to be a part of, and hopefully we can keep the ball rolling and making it something better still. In fact in my opinion it was a unifying thread in some respects, and it dissolved a lot of the mysteries surrounding Linux/Ubuntu and a great deal of good came from it.

So overall, I just want to say great job to all of those involved in the “Security for Newbies Thread” and the associated wiki it spawned.

So without further ado by name thanks here it goes

  • MrLeek – The thread as your idea, and though it was a rocky start, it wouldn’t have happened without your idea and contributions.
  • Ms. Daisy – Probably the individual who put the most time in editing building and otherwise organizing a giant conglomeration of ideas and thoughts. Probably also the largest learning curve achieved (MVP anyone?). Ambitions for blue team (see you soon ;-))
  • Olle Wiklund – Contributed multiple ideas, as well as marketed the idea of the wiki and promoted it to individuals who desired learning.
  • Haqking – An infosec professional with like a billion years of experience and a really good friend of mine, who’s contributions to the thread helped greatly (as well as a good place for me to vent some frustrations) Also note worthy this man is lethal with google 😉
  • Thewhistlingwind – Keeping the thread on track with grounded and practical knowledge of application in security concepts. To quote a song by The Offspring “you’re gonna go far kid.”
  • vasa1 – you only made a few posts, but you helped guide the direction of it more than you probably realize (as I was putting in research for different concepts in the thread I kept finding your name in most of the things I looked up lol.
  • mrwoof – Router security tips, simple things that most people don’t look at but can end up devestating quickly
  • BlinkinCat – Encouraging the thread and FAQ in its infantile stages
  • tartalo – Also encouragement, probably when the project needed it the most
  • Spartacux – I know I give you crap for wearing your “tin foil hat” too much, but you made some great points, and though a lot of the privacy related stuff didn’t make it to the wiki your points will still be heard through the thread.
  • dflyer – While I disagree with the usefulness of shieldsup and anything else made by Steve Gibson, it does have its purposes, and can help educate users (mostly correctly) in the state of TCP ports. +1 for contributing a resource that speaks clearly to some people.
  • OpSecShellshock – Another talented infosec professional, I’m pretty sure this individual knows everything there is to know about web based vulnerabilities, well done and thank you for taking the time.
  • crazyguy50 – For elaborating very concisely what shields up does. (you did miss the part about selling subscriptions to zone alarm though :-P)
  • CharlesA – IT professional, and well on his way to becoming a member of the Infosec field, keep at it, you’ll make it you’ve got your head in the right place. Generally cool guy and official mod mascot 😉
  • Bukie – Awesome points on passwords, even more winning for sending the thread into a 2 day debate about divulging password constructs
  • desukane – Contributed by bringing the wiki back to a level of speaking to its target audience (which was not in fact at B-Sides)
  • Lisati – For bringing a GOOD choice of beer and differentiating two very important social groups “hackers” and “crackers” hackers make money legally and shower, this is the difference. 😉
  • jramshu – For bringing some good points to the thread as well as a healthy sense of paranoia (and on a personal note for reminding me that we should in fact NOT mess with Texas)
  • Orangecrate – by providing a dissenting opinion, you can’t make a document relevant if you can’t make it important to those who couldn’t care less.
  • leoquant – valid points about targeting of certain platforms flash in particular
  • Vanhenjyr – for pointing out the fact that some of this stuff is really hard to embrace, thus spawning the NoScript configuration guide 🙂
  • Many Anonymous Contributors – For those who didn’t want to be recognized, you’re still getting recognized. Thank you for your contributions
  • If I missed you in any way — please send me a message on the forum I will add you to the list if you want to be, if you do NOT want to be on this list let me know I will take you of as well.

    Also this project is not dead, or finished, if you’d like to contribute feel free to join in 🙂

    Have a great weekend everyone!
    (read I’ll see you on the forums tomorrow morning lol)

This is a quick tutorial for compiling Snort from source on Ubuntu 10.04.3 Server. This tutorial assumes you have a LAMP stack running, if you don’t, you need it it can be installed via

sudo apt-get install lamp-server^

Step 1 : Dependencies

Satisfy all the dependencies of Snort and daq 0.6.2

sudo apt-get update && sudo apt-get install nmap nbtscan libpcap0.8-dev libpcre3-dev g++ bison flex libpcap-ruby libdumbnet-dev zlib1g-dev

Step 2 : Download Snort and daq

Snort : Snort

DAQ : DAQ 0.6.2

Step 3 : Installing DAQ

In the directory of your daq download do the following

sudo tar zxvf daq-0.6.2.tar.gz
cd daq-0.6.2
sudo ./configure
sudo make
sudo make install
sudo ldconfig

Step 4 : Installing Snort

In the directory of your snort download do the following

sudo tar xzvf snort-
cd snort-
sudo ./configure --prefix=/usr/local/snort
sudo make
sudo make install
sudo mkdir /var/log/snort
sudo mkdir /var/snort
sudo groupadd snort
sudo useradd -g snort snort
sudo chown snort:snort /var/log/snort

Step 5 : Create Snort database

Create the database

echo "create database snort;" | mysql -u root -p
mysql -u root -p -D snort < ./schemas/create_mysql

Create the Snort DB user

echo "grant create, insert, select, delete, update on snort.* to snort@localhost \
identified by 'YOURPASSWORD'" | mysql -u root -p

At this point you’re good to go, just install the latest rules snapshot and configure snort as you’d like. Enjoy 🙂


With the release of Ubuntu 11.10 Oneiric Ocelot upon us, I decided I would discuss one of the lesser used security features bundled with Ubuntu, Apparmor. Apparmor is actually a great utility particularly in terms of desktop security where browser exploits can become ridiculous quickly. It is suited for production applications as well, however often times is forgone due to the resources confining an application can require.

This guide is designed for the desktop user who all too often chooses not to use Apparmor for the reason, it’s too complicated, it’s a very advanced task, there are no premade profiles for my software; whatever the reason Apparmor is a great security feature, and while us Ubuntu users don’t have something super convenient like YaST to help us configure it, we can still create our own Apparmor profiles with relative ease.

For those of you who don’t understand what Apparmor does but just know that it’s a good thing to have. A quick explanation is, it limits what an application can and can not do, by utilizing a profile with a pre defined set of controls. If the application tries to exceed that profile it will not be allowed. This is useful for countering the dreaded 0 day exploit. Apparmor will essentially limit the exploit code to exercising the program’s functionality. While this still may be undesirable it is much less devestating than the alternatives.

This guide was created with the aim of showing a Novice user how to create their own Apparmor profile, it was created using the oh so awesome and new Oneiric Ocelot, but should work on Lucid Lynx, Maverick Meerkat and Natty Narwhal, anything older I can’t guarantee, although Apparmor hasn’t really changed that much so most will likely still apply.

Making sure we have all the necessaries

Before we delve into creating our Apparmor profile let’s make sure we have all the necessary tools in this case I’m referring to the Apparmor utilities package. We can get it by doing the following

sudo apt-get install apparmor-utils

For this guide we will be constructing a profile for Chromium Browser you can install it by doing the following

sudo apt-get install chromium-browser

Understanding Apparmor Profile Syntax

I will be walking you through the creation process , as well as some of the syntax options we choose and why, however it is wise that you familiarize yourself with all available parameters here

A brief summary of syntax and parameters :

#include – includes abstractions from another profile to help simplify the profile creation process
capability – adds a capability on a per-thread basis (eg : capability sys_admin , capability dac_override)
network – adds networking capabilities (eg : network inet stream)
Access modes
– r : read
– w : write (don’t use with append)
– a : append (don’t use with write)
– ux : unconfined execute
– Ux : unconfined execute with a steralized environment
– px : discrete profile execution
– Px : discrete profile execution with steralized environment
– m : protected execute utilizing mmap()
– l : link
– k : lock

As I said, if you need more information on the function of these check the link here for a more in depth explanation.

Creating our Apparmor Profile

The first step in generating our Apparmor profile for Chromium is to type the following in a terminal

sudo aa-genprof chromium-browser


this tells Apparmor we to generate a profile for /usr/bin/chromium-browser. Once you’ve entered this command you will be prompted to “Scan for system events” , before we do this we need to start Chromium and exercise it’s functionality. Start it up, visit some websites and generally use the browser as you normally would.

Once we’ve done this we can hit “S” to scan for system events. You will be given some choices on what chromium will have access to, this is where it gets a little complicated, and we need to understand what chromium is doing with them.

The first we will be given is /bin/readlink : we can grant ix (inherit execute) to this by pressing X

The next option is /etc/chromium-browser/default : this is our chromium configuration and we can give this r so we press A for Allow

After this we can allow w in /home/*/.config/chromium/FirstRun by pressing A, now here we are given a choice of /home/username/.config/chromium/FirstRun or /home/*/.config/FirstRun, the * acts just as you would expect a wildcard which means match any name we use our arrow keys to scroll down to this and use this option because it makes our profile more portable, we may not always have the same user running our confined application.

The next choice is to allow read in /proc/meminfo , we want to do this so that chromium can manage shared memory , so we choose A for Allow.

The next option is to allow read in /usr/bin/chromium-browser , we want to be able to run our browser so we choose A for Allow, we may have to come back and tune this.

Next we have the option to allow read in /usr/share/icons/Humanity/devices/16/drive/drive-harddisk.svg or to add an abstraction that gives us access to this path, for this we will scroll up to #include and hit enter

After this we will be prompted to save our file. We will press S to do so.

Debugging our Profile

At this point we have a shell of a profile generated for Chromium in /etc/apparmor.d/usr.bin.chromium-browser , we can view it and edit it by doing the following

sudo nano /etc/apparmor.d/usr.bin.chromium-browser

As you might imagine our profile is far from complete, so we will now edit it with our text editor.

The first thing we will want to add to our profile is

#include <abstractions/audio>
#include <abstractions/nameservice>

This will insure that chromium has access to audio and dns lookups.

Debugging the profile manually

Many people will say to place the profile into complain mode via

sudo aa-complain usr.bin.chromium-browser

Then use the application for awhile and run

sudo aa-logprof

To go through the options of what to allow and disallow. This is a good option, but it takes a really long time, so what we’re going to do is debug the profile manually. In a seperate terminal window (not as root) we are going to run chromium-browser and watch for errors.

The first error we can see is that we don’t have access to /etc/lsb-release. We can grant access to that by adding the following to our apparmor profile

/etc/lsb-release r,

At this point we can reload our profiles by doing the following

sudo /etc/init.d/apparmor reload

and attempt to execute chromium-browser again. This time we are told we don’t have permission to acces /usr/lib/chromium-browser/chromium-browser we can add the following to our profile

/usr/lib/chromium-browser/* r,

we can use the star because it is safe to say that Chromium should at LEAST be able to read everything in it’s directory. As we can see that is not enough, as we are still presented with the same error after reload. We can get around this by adding

/usr/lib/chromium-browser/chromium-browser rix,

To give execute permissions to the chromium-browser file. Our next error shows that chromium-browser-sandbox in the same directory is also needed, in order to insure the least amount of permissions given are, we add the following instead of a wildcard.

/usr/lib/chromium-browser/chromium-browser-sandbox rix,

Our next error is failed to move to PID namespace we will add the following to our profile

capability sys_admin,

/proc/*/fd r,
/prox/*/auxv r,

Our next error is slightly more cryptic but essentially says cannot chroot into /proc so we need to add the following to our profile

capability setgid,
capability setuid,
capability sys_chroot,
capability sys_ptrace,
capability dac_readsearch,

/proc/ r,
/proc/*/status r,
/proc/sys/kernel/shmmax r,

Remember if you stop being able to understand what you need to do at any time you can always run

sudo aa-logprof

And Apparmor will give you suggestions based on syslog events.

Our next set of errors give us this can’t access /sys/bus/pci/devices

so we will add

/sys/bus/pci/devices/* r,
/dev/shm/** rwk,

Now we are still getting some errors, so now is a great time to run aa-logprof and get some suggestions it will add the following

/usr/lib{,32,64}/** rw,
/etc/chromium-browser/policies/** rw,

The next set of errors will all have to do with /sys/bus/pci/devices/0000:00:00.0/* So we’re going to cheat a little bit here, since if you notice the addresses are just incrementing between 4 different files we can do add the following two lines

/sys/bus/pci/devices/0000:00:0[0-9].[0-9]/* r,
/sys/bus/pci/devices/0000:00:0[a-d].[0-93]/* r,

Or you can add them each individually as the errors come, I just thought I would give you the cheater mode [a-d] matches any letter a through d , [0-9] matches any number 0 through 9.

This time we’ll see, when we start it works.

We should now have a profile that looks something like this

/usr/bin/chromium-browser {
#include <abstractions/audio>
#include <abstractions/base>
#include <abstractions/gnome>
#include <abstractions/nameservice>

capability dac_override,
capability dac_read_search,
capability setgid,
capability setuid,
capability sys_admin,
capability sys_chroot,
capability sys_ptrace,

owner @{HOME}/** rw,
/bin/dash ix,
/bin/readlink rix,
/dev/shm/** rwk,
/etc/chromium-browser/default r,
/etc/chromium-browser/policies/** r,
/etc/lsb-release r,
/home/*/.config/chromium/Default/* k,
“/home/*/.config/chromium/First Run” w,
/home/*/.pki/nssdb/cert9.db k,
/home/*/.pki/nssdb/key4.db k,
/proc/ r,
/proc/*/auxv r,
/proc/*/fd/ r,
/proc/*/status r,
/proc/meminfo r,
/proc/sys/kernel/shmmax r,
/run/shm/* rw,
/sys/bus/pci/devices/ r,
/sys/bus/pci/devices/* r,
/sys/devices/pci0000:00/0000:00:0[0-9].[0-9]/* r,
/sys/devices/pci0000:00/0000:00:0[a-f].[0-9]/* r,
/usr/bin/chromium-browser r,
/usr/bin/xdg-settings rix,
/usr/lib/chromium-browser/* r,
/usr/lib/chromium-browser/chromium-browser rix,
/usr/lib/chromium-browser/chromium-browser-sandbox rix,
/usr/lib{,32,64}/** rw,
/var/lib/dbus/machine-id r,



Hopefully this will make it easier for you to create your own apparmor profiles more quickly without having to spend days in “learning mode” for your applications. Also if you end up having any problems, with your profile in the future as your needs grow you can always go back and debug your profile with aa-logprof or manually via a terminal.

Thanks for reading I hope everyone is having a GREAT weekend! 🙂

Users migrating from Windows to Ubuntu are constantly asking, “which is the best anti-virus for Ubuntu?” Or, “Do I need anti-virus for Ubuntu?” The only constant is the replies that are given on support forums and IRC chat rooms. The basic consensus is that Ubuntu is more secure, and isn’t plagued by malware like Windows is. Now while that is true to an extent, I am hesitant to build any security model on the “honor system”. A system that says , we don’t need anti-malware solutions because the bad guys aren’t targeting us. That sentence should actually read: “the bad guys aren’t targeting us today“.

Quite simply put, if malware developers were to decide tomorrow that they wanted to target the Linux or Ubuntu desktop user base, it wouldn’t be that hard. It’s really no different than targeting Windows, the only real difficulty is that memory addressing across distributions for vulnerable applications might change considerably. However, with the readily available supply of free open source software, modifying exploit code to exploit vulnerabilities in a multi-distro environment really wouldn’t be all that difficult.

So what we are going to look at today is a typical Ubuntu 10.04.3 LTS install, fully updated running no services. We are going to compromise it and install malware. Then we are going to see which (if any) of the three leading free anti-malware solutions can find and eliminate our malware. The three solutions we will be testing today are AVG Home Linux edition, Avast! Linux edition and the ever popular ClamAV.

The Victim

As always we have our victim set up, this is a standard desktop install of Ubuntu 10.04.3 LTS, fully update, running no services, all applications are unmodified and downloaded from the repositories.

What this system looks like to an external attacker

What we’ve done here, quite simply is to create a site that creates a shell by loading malicious javascript and injecting a payload. This is nothing new, in fact it’s pretty typical and is often called a “Drive-by-download”. This works under Ubuntu because our payload is crafted to work under Linux. Once we have the shell we are then free to do as we please (note we are walking through this manually all of this could be automated).

*note : If we were using NoScript here the compromise would not have occured.

Now our malware is installed, again this would normally be an automated process, however we’re breaking it down to understand the different steps that occur here. Our malware is pretty simple in this case, it does only a few things, it key logs so that we can capture credentials, and it opens a reverse shell and a bind shell. This allows the attacker to read the keylogs and escalate privileges once a password has been uncovered. The malware being “trapped” in the home directory perpetuates itself by adding itself to the compromised user’s .bash_profile.

Now that we have installed our malware, and we can see it’s working, we will try out the top three free Anti Malware solutions, for Linux/Ubuntu. They should find two files suspicious in nature linuxmalware and

What this system looks like for us after the compromise


So, I have the latest version of Avast! for Linux available, and I updated the definitions. I did a scan of our home folder, where our malicious files are stored /home/.mozilla/firefox to be precise. The results, Avast! found nothing wrong whatsoever.

AVG Anti-Virus

I would have liked to have gotten the results from AVG, however the current version of AVG did not work when installed under Ubuntu 10.04.3 LTS, either from .deb or compiled from source. If someone knows how to stop it from segmentation faulting on scan, please inform me, I would love to know if it detected this, as the Windows version does detect these files as malicious.


As we can see, ClamAV also did not find our files particularly malicious or interesting in nature.


Seeing as though none of our scanning engines detected a reverse shell, bind shell, or keylogger. We can pretty much say that the Ubuntu community is NOT properly prepared if malware authors DO start targeting our desktop systems. The past few years have seen marginal increases in Linux based malware threats, and as the operating system becomes more popular in the home user space I’m sure it will begin to draw the attention of malware developers.

I keep harping on these points in my posts for two reasons. One — Malware can be propogated in Linux the same way it can be in Windows, it just isn’t. Two , if it ever is, the Linux community will be unprepared for it. So the next time you’re arguing why mainstream developers don’t go near Linux, keep in mind, its security may be highly over-rated.

I also highly recommend that you use NoScript, since these types of attacks can very easily be targeted at the Ubuntu and Linux communities. The fact that they aren’t is sheer luck in my personal opinion.