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.

eDirectory Profile

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
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

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..

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

No Comments
By: jjaimon
Aug 13, 2009
9:47 am
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow