Re: [RFC] linux-2.6.10-auditfs-tc1.patch
* Serge Hallyn (serue(a)us.ibm.com) wrote:
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.
Yeah, guess that's a job for benchmarking.
> 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...
I agree with Steve, I think that LSPP would require security labels in
audit message.
> > * 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.
I think you'll get interesting output with hardlinks. As in the path
used to establish the watchpoint to the inode, not the path used to
access the inode.
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.
Yes, so you'd either have to maintain watchlists all the way back to /,
and rebuild or keep this type of updating done in userspace. The latter
will be lossy. Also, you don't quite lose the watch entry, you should
keep it for the underlying /etc/passwd, which some apps may be using.
For example, one method of containment is to do bind mounts into a
private namespace. So mount --bind /dev/null /etc/passwd for some
contained process, access to /etc/passwd is pretty unintersting unless
it's the real underlying inode.
(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?
I don't think we want to dig into pathnames. Mount could be modified,
but it'd have to be after the mount succeeded, so might as well use
notification.
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
usefulness.
Speaking of inotify, what happened to trying to have some similar
mechanism? It'd be nice for audit to open an event channel that's fed
by a common mechanism to inotify.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net