[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: User file access auditing



On Fri, 2004-10-22 at 14:46, Barry Roomberg wrote:
> I would like to create a shared dir tree that certain users have full
> access to.  Every file access that reads or writes data (stat, open,
> read, write, delete, rename, ???) should be logged, while still allowing
> the operation to complete.
> 
> Is SELinux appropriate for that type of tracking?
> 
> If so, can anyone give me a hint on the way to construct the policy?

First, I'd recommend adding "audit=1" to the kernel command line in your
/etc/grub.conf, so that the kernel audit framework will also emit a
syscall audit record upon syscall exit whenever SELinux generates an
audit message during the processing of a syscall.  The audit messages
will be separate, but will share the same timestamp/serial number so
that they can be correlated.

Then, under /etc/security/selinux/src/policy, you can add your policy
statements, something like the below rules, possibly as a
domains/misc/local.te file to avoid conflicts with any future policy
updates to the rest of the policy:
# Define a type for files to be audited.
type audited_file_t, file_type, sysadmfile;
# Allow all user domains to create and modify these files.
allow userdomain audited_file_t:dir create_dir_perms;
allow userdomain audited_file_t:{ file lnk_file } create_file_perms;
# Audit all accesses by user domains to these files.
auditallow userdomain audited_file_t:{ dir file lnk_file } *;

That might not be exactly what you want, e.g. you might want to limit
access to a specific user role/domain, and you may not want to audit
everything in truth (e.g. searches of directories), but gives you the
idea.

One caveat:  SELinux permission checks and auditing only occur after the
existing Linux DAC checks, so if Linux DAC denies access (due to file
ownership/mode), you'll never reach SELinux at all and won't get an
audit message from it.  But if these files are intended to be accessible
to these users, that shouldn't be a problem, I would think.

-- 
Stephen Smalley <sds epoch ncsc mil>
National Security Agency


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]