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

Re: [RFC] linux-2.6.10-auditfs-tc1.patch

On Thu, 2005-01-20 at 19:20 -0800, Chris Wright wrote:
> > * Add RCU locking in the appropriate places to make SMP-safe
> Is RCU a requirement, or just some real locking?

rwlocking should suffice for now, but eventually a spinlock to prevent
concurrent writers and rcu to prevent deletion of a watch entry while
another process is using it seems ideal.

Given his ambitious goals of doing locking overnight, I think rwlocks
are the way to go for now :)

> Seems intuitively useful to at least be able to watch a file regardless
> of who touched it, or what syscall was used.  I think you'd especially
> want to know if you had some non uid=0 process that wrote to a sensitive
> file abusing it's CAP_DAC_OVERRIDE privilege for example.

Perhaps we should print out current->cap_effective?  Or is that
overkill?  Or perhaps an actual "security_identify_process(task, buf,
len)" hook would be useful, where commoncap could print out the
capabilities, and selinux could print out the context.  Maybe that's
closer to debug info...

> > * Add/remove unnecessary information about the file or directory being
> > collected in the audit context.  Input on this?
> I missed which parts are unnecessary?

It sounds like he's worried about the 7 line audit_log_format line he
has, but I think that's all good info.

How do people feel about the general approach and limitations?  For
instance,  you can't ask to watch /etc/passwd if /etc does not yet
exist, or, if you ask to watch /etc/passwd, then mount another fs
over /etc, you quietly lose that watch entry.  (Tim: please correct me
if I'm wrong)  The alternative, however, is to deal with deeper
pathnames in the kernel, which is always frowned upon.  Are we satisfied
with saying that 'mount' could be modified in userspace to do the right
thing in recreating watch entries?  Perhaps we could even use inotify +
a userspace daemon for the mkdir /etc case, to create new audit entries
based on some config file.  This goes beyond CAPP requirements (else
inotify would not suffice), and into what seems to me to be real world


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