View source for ASL Security Model

Security In Depth


The short version here, theres more than one way to do it. 

ASL is a similar design to PSA, its reconfiguring the packages underneath, like mod_security, ossec, the kernel, etc, based on your security model. Granted I'm bundling those rpms as well, but theres nothing to stop you from taking them apart to tinker (source code is available). 

I dont spend a lot of time down in the weeds on the specific packages installed on the system as a security control. In years gone by that was the security model used when there werent any better alternatives. SELinux, and GRSecurity being two of the bigger ones to change that security model with what is called Role Based Access Control (RBAC). With an RBAC system you could have gcc, perl modules, etc installed on the system, and block access to them even by the root user. In practice, its like password protecting applications. 

It helps a lot if you have a good solid understanding of the threat first. With hosting your threat is about 90% web based applications, and 10% everything else. This is compounded further because you're most likely not in control of those applications, or if you are, in a position to change them if they're vulnerable to exploitation. This is assuming you even know what is there in the first place. The model used by the attacker is use those exploitable applications to upload their tools to further control the system. Methods used to block that have involved removing applications like wget, curl, etc, or mounting the tmp partitions noexec. The  attackers respond by uploading their own versions of wget, running from apache writable directories, or an even more trivial model, using shell/perl/python/ruby/php scripts (this gets around noexec). 

So your security model needs to address the following:
1) You cannot remediate your vulnerable applications (too many/unknown)
2) Removing tools is ineffective (attackers upload their own)
3) noexec settings do not stop these tools from being run (trivial to bypass)

Response:
1) Input validation, before traffic gets to those applications, with mod_security, and suhosin. When this fails

2) Use kernel level security controls to control the context in which applications can execute. IE, Trusted Path Execution in GRsecurity is a great example of a simple security model. Untrusted users can only execute commands owned by root.  This is further enhanced by user-id level firewall rules, untrusted users can only use these ports, or contact these addresses. When this fails 

3) Host based IDS to track file integrity checks, and automatically respond to host based security events.

Im hardly scratching the surface with item #2 there. The security controls in SELinux and Grsecurity are far more granular than I could articulate in brief. SELinux data-labeling being a prime example. If the app isnt labeled correctly, it wont run by anything (not php, sh, perl, etc) by any user, including root. You cant even move an application labeled at one security level down to a lower one, or even cut and paste between them. Its quite a powerful tool for securing hosting environments, closing off nearly every method an attacker could use to load exploit code to a system. I'm aiming for this to be the heart of the ASL 3.0 release.