If you are using the Trusted Path Execution (TPE) features in ASL you may be protected from the glibc vulnerability that is currently unpublished (we are sworn to secrecy on the exact details, its not public yet). We do recommend that everyone upgrade their glibc to the latest release from their vendor which includes a fix for this vulnerability. Defense in depth is always a good idea, and you should never rely on one thing to protect you.

ASL can also protect against this vulnerability in some cases if you are using dazuko in ASL. We do have signatures for the exploitation tools, which will prevent them from running. ASL can also prevent the exploitation tool from running even if we dont signatures for it or if dazuko was disabled (the default is disabled currently) even though your system is still vulnerable via TPE (which is a much stronger protection than dazuko in this case).

We recommend you upgrade glibc and configure your system to not trust all your users. The default configuration in ASL is to not trust specific users (apache for example) and to trust the rest. If the exploit was uploaded by one of the untrusted users, it would not run (even though the system may be vulnerable), if it was uploaded by a trusted user (which is most of the users on the system by default) it may run if you have dazuko disabled or if we don't have signature for this tool (which could happen).

Therefore, we recommend you upgrade glibc and configure your system to not trust your users. If you have configured ASL to not trust all your users then theres no way for anyone to run the exploit tool - thats the ideal case - it helps to protect against zero day vulnerabilities. ASL also has more advanced features in the RBAC system that make it really impossible to exploit, but we will not going into RBAC configurations here. They require tuning for your system, and each configuration will be different.

There are two ways to configure your system in this secure state. The first way is available in the current the stable kernel, and we are adding a new way into the latest testing kernel (which will be released this week):

Currently method:

By default ASL trusts all users (as do all Linux systems) and only sets certain users as untrusted. Some of them are:

bin,daemon,adm,etc.

This will vary from system to system, as not all of these users exist.

You can add users to this list, although that means you need to keep this list up to date as you add users to the system - or configure your system to automatically add users to the untrusted group. The untrusted groups default GID is 1005.

One quick way to add all your users is to run this command to generate a list of all users on the system fit for inclusion in /etc/groups:

cat /etc/passwd | awk -F: '{print $1}'|egrep -v "^root$" | tr \\n ,

Which will generate a line like this (yours will vary):

bin,daemon,adm,lp,syncm,user1,user2,user3

Just change this line in /etc/group:

untrusted:x:1005:bin,daemon,adm,lp,syncm

To your newly generated line (dont delete untrusted:x:1005:):

untrusted:x:1005:bin,daemon,adm,lp,syncm,user1,user2,user3

Now all your users are untrusted. If you wish to make this the default behavior when a new user is added to your system, please see your operating systems documentation for assistance.

Option 2 (which will be available in a testing kernel later this week) is to invert this logic: All users are untrusted unless you specifically add them to the trusted group.

To change ASLs behavior to not trust any user, and instead require you to specifically add users to the "trusted" group.

To do this, you need to be running the upcoming ASL testing kernel. We'll, as always, post an announcement when its available.

Step 1) Change the list of users for the "untrusted" group to only those users you want to trust.

Edit /etc/group

Change this line:

untrusted:x:1005:bin,daemon,adm,lp,syncm,user1,user2,user3
To:

untrusted:x:1005:trusteduser1,trusteduser2

Optional Step 2) Change the name of the group to "trusted". You dont have to do this (ASL doesnt care what you call it) - but for sanities sake you should give it a name that reflects what it is now.

untrusted:x:1005:trusteduser1,trusteduser2

trusted:x:1005:trusteduser1,trusteduser2

Step 3) Change this setting in /proc (you will need to do this on boot before S99):

One way to do this is to create the file "S98custom_asl" in /etc/rc3.d: (if your system is configured to start at runlevel 3, check your systems config if you arent sure)

Option 1)

Add it to your sysctl.conf file:

grsecurity.tpe_invert=1

Option 2) create a custom init script

/etc/rc3.d/S98custom_asl

#!/bin/bash
echo 1 > /proc/sys/kernel/grsecurity/tpe_invert

And make sure your script is executable (by default Linux scripts are NOT):

chmod u+x /etc/rc3.d/S98custom_asl

And reboot. Make sure you do this on a test system first - you are inverting the TPE logic, which means if you have uids that need to be able to run programs they own (a bad idea btw) they wont be able to unless you trust them.