by Jaimon Jose
AppArmor is an application security tool designed to provide an easy-to-use security framework for your applications. AppArmor pro-actively protects the operating system and applications from external or internal threats, even zero-day attacks, by enforcing good behavior and preventing even unknown application flaws from being exploited. AppArmor security policies, called “profiles”, completely define what system resources individual applications can access, and with what privileges.
The main areas that AppArmor can protect are:
- Files the application can access
- POSIX.1e capabilities
eDirectory being an infrastructure and security component, can be protected by AppArmor. This paper is an attempt to create a basic profile for eDirectory.
Given below is a sample eDirectory Profile.
AppArmor protects the file and net access based on the above profile. We can call the above list as a white list and any access outside of the above file locations are considered as black list.
How do we verify if eDirectory is protected.
AppArmor expects the profiles to be in the following location.
/etc/subdomain.d/ -> SLES9 /etc/apparmor.d/ -> SLES10 and SLES11
The profile names are based on the absolute name of the binary by replacing the ?g/’ with ‘.’. For eg. the profile name for eDirectory would be opt.novell.eDirectory.sbin.ndsd
AppArmor provides a set of tools to verify and validate application protection level.
jjaimon:~ # unconfined 6690 /usr/sbin/sshd not confined 19352 /opt/novell/eDirectory/sbin/ndsd confined by '/opt/novell/eDirectory/sbin/ndsd (enforce)'
AppArmor uses a user space daemon (/usr/sbin/aa-eventd) for reporting and alerting. This daemon monitors log traffic, sends out notifications, and runs scheduled reports. It does not require any end user configuration and it is started automatically as part of the security event notification. In absence of this daemon, AppArmor sends the auditlog to syslog.
jjaimon:~ # tail -f /var/log/audit/audit.log type=APPARMOR msg=audit(1165496085.726:445): PERMITTING r access to /etc/opt/novell/nici.cfg (ndsd(19393) profile /opt/novell/eDirectory/sbin/ndsd active /opt/novell/eDirectory/sbin/ndsd) type=APPARMOR msg=audit(1165496145.738:446): PERMITTING r access to /etc/opt/novell/nici.cfg (ndsd(19393) profile /opt/novell/eDirectory/sbin/ndsd active /opt/novell/eDirectory/sbin/ndsd)
Can AppArmor be the one stop solution for all application security?
We can’t consider AppArmor as the one stop solution for eDirectory application security. The main advantages of using an AppArmor profile are:
- Easy to build and tweak the application profiles
- File system protection from eDirectory process space.
However, the above advantages alone are not sufficient.
- eDirectory, being an authentication and authorization infrastructure, needs to have its
own auditing and logging. AppArmor auditing will only cover the access pattern based on the AppArmor profile. In this case, it will be mostly file system access.
- We need a way to build a white list of network ports or interfaces that the application can use. AppArmor uses capabilities as defined by POSIX.1e. The defined capabilities in the above profile will give sufficient privilege to the application to open any ports below 1024. This will be damaging. For eg.
Allow various network-related operations (e.g., setting privileged socket options, enabling multicasting, interface configuration, modifying routing tables).
Allow binding to Internet domain reserved socket ports (port numbers less than 1024).
- AppArmor can not be used to run specific modules or threads of an application in a less privileged mode. This will be more useful for multi-threaded applications like eDirectory.
- AppArmor reads syslog for application messages. eDirectory uses its own logging mechanism and all messages are logged to ndsd.log.
A well defined AppArmor application profile clearly protects the system from a witty attacker taking over your file system. However, AppArmor alone may not be an answer for complete system protection.
eDirectory should be run as a jailed process if you need complete process isolation. Couple of disadvantages mentioned above – lack of ability to protect privileged port and the ability to read custom log files- seem to be a drawback. The default eDirectory (download attachment below) profile should be updated if additional services are configured along with eDirectory. For eg. Domain Services for Windows, OES..