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

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

* Serge Hallyn (serue 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

> 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.

Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

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