Re: Auditing - Snare, LAuS, SELinux
Someone wrote:
What about audit hooks that provide the following services for
selinux
and other LSM frameworks:
- a function that tells the audit framework
"I decided to audit this system call, please do that for me"
- a function that tells the audit framework
"here's an additional blob of information, please attach that
to the audit record"
Would that be sufficient? What else would be required?
You can look at the audit_* calls made by SELinux today using the
existing audit framework for reference, e.g.
audit_log_start/end/format/d_path. One important point here is that the
existing framework will emit an audit record immediately for SELinux but
allows that audit record to be associated with other audit records for a
given syscall using a serial number. In some cases, a SELinux-generated
audit message will not be associated with a syscall at all, as SELinux
permission checks can occur from interrupt or bh.
Would it be better to allow selinux to use the generic filtering
machinery
of the audit subsystem? In that case, it would need a mechanism to specify
additional bits of information that could be used in filter evaluation,
such as object labels, caller roles, etc.
When SELinux gets an access control decision from the policy, it also
gets auditing decisions at the same time based on the same inputs. The
policy already supports specifying whether or not a given permission
check for a given pair of security labels should be audited when granted
and/or denied. So I'm not sure that there is anything to be gained by
providing similar functionality in the audit framework, and doing so
would require moving knowledge about security labels into the audit
framework (or at least providing callbacks into SELinux to compare
them).
However, you have made my mind wander on to things like a
is_file_audited() call...
ie:
for FILE in /etc/passwd, /etc/shadow, /usr/local/etc/something:
if(!is_file_audited(FILE)) {
set_file_audited(FILE)
.. but this would be way too complex to manage, with the possibility of
either:
* A rule for every file on the file system, or
* A new flag attached to every inode (or selinux label? (Posix ACL
integration?) and some open() mangling, or
* Some sort of dynamic rule-optimisation code (yuk).
SELinux already supports auditing based on security labels. Stephen
Tweedie further suggested introducing a separate security.audit
attribute for files that would allow you to mark a file for auditing
without necessarily using a separate security label on it (or without
even SELinux at all). Using attributes is definitely preferable to
pathname-based approaches, as it allows you to unambigously mark the
real object and avoids the usual pathname manipulation games.
> Ok, In summary, it sounds like we:
> * Want to make audit independent of SELinux - even the file-audit
> settings
This seems to be a popular request. Do people prefer we start with
replicating the SELinux functionality and making a clean separation
between the two, or using SELinux as a base and adding audit specfic
extensions?
While I agree that your audit framework needs to support auditing even
without SELinux, it is important to note that SELinux does confer
definite advantages for auditing, both in providing a meaningful basis
for audit decisions (the security labels, which can provide real
information about the confidentiality and integrity properties of the
object) and in protecting the userspace components and audit logs (and
potentially providing better least privilege for the kernel audit API as
well).
> * Want to make it easy for the selinux guys (or any other
module
> provider) to inject audit log data 'through' the audit subsystem.
> * Go with a binary format between kernel and daemon, but ensure that the
> logs are written in text format.
I suggest that we preserve the text interface for SELinux, making the
binary format an option. LAuS stored the audit records in binary format
which required audit specific tools, augrep, aucat, to analyze the data.
Did 'aucat -F' ever get fixed? ccb? Thomas? :-)
I agree with writing the records in text format.
Security contexts will remain as strings regardless of the audit format,
as there is no binary representation of them that is exported to
userspace. Likewise for exe and path information. Classes and access
vectors could conceivably be emitted in binary form rather than the
current translation to text performed by SELinux, but that then imposes
a consistency requirement on some userspace tool to have the same
mappings that are presently in use by the kernel, which seems prone to
error.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency