I spent most of last week in Boston, attending the Red Hat Summit. This is an annual show put on by Red Hat to discuss various topics of interest to their customers, partners and analysis. I was there because Likewise is a Red Hat partner and because we received an Innovator of the Year award.
I sat in on various sessions. One of the most interesting ones was an update on changes to the auditing system in the Linux kernel and in the associated Red Hat tools.
What is auditing? Auditing is the ability to detect access to specific resources and to note who performed the access and when the access was performed. Examples of this are auditing when someone reads from or writes to the /etc/passwd in UNIX or when someone tries to add a member to the Domain Admins group in Windows Active Directory. In both of these cases, there might be completely legitimate reasons for such access. Auditing is about collecting information, not about enforcing security. Of course, if security is violated, auditing information can provide forensic evidence to discover whodunnit and what was dun.
The auditing system in Red Hat and others versions of Linux is implemented by a combination of kernel modifications and code in the auditd daemon. Auditd reads configuration files and informs the kernel what information it’s interested in. When relevant events are detected in the kernel, it signals back to auditd that, in turn, generates log information and/or passes information to other interested parties.
Auditd provides a rich set of things that can be audited. For example, any system call can be logged as can access to any file.
Configuring auditd is not trivial. Here’s a link to a page that describes how it’s done. Additionally, if you want to read audit output, it can be messy, too.
As with most things UNIX-y, there’s little consistency between versions. Linux offers one thing. Solaris, HPUX and AIX all offer something different (from Linux and from each other!). They all do more or less the same thing.
And then there’s Windows.
Windows takes a fundamentally different approach to auditing. In Windows, the auditing mechanism is almost identical to its security mechanism. Security is implemented by using access control lists (ACLs). So is auditing.
Windows supports two types of ACLs: discretionary ACLs (DACLs) and system ACLs (SACLs). The former is used for security, the latter for auditing. Just as Windows uses a DACL to determine if a user has access to a resource, it uses the SACL to determine whether or not the access should be logged. Log output is sent to event logs.
The ACL approach means that Windows can audit access to any resource that has ACLs associated with it. You can audit access to a file (or to entire directories since ACLs are “inherited”). You can also audit access to registry entries or nodes in Active Directory. Of course, things without ACLs cannot be audited. You can’t audit when an application calls a specific system call, for example.
OS auditing is a very powerful feature that can give you assurances that your security systems are working effectively and that your privileged users are not unnecessarily accessing restricted data. Even in Windows, however, where configuring the audit system is easy, I think the features are underutilized. In UNIX/Linux/Mac I suspect they’re used by fewer than 5% of users.