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

Re: [PATCH] enable /proc/$$/loginuid

On Tue, 2005-01-18 at 11:15, Serge Hallyn wrote:
> I'm assuming the loginuid needs to be set at the first login, and be
> immutable.  Let's say we have an audit rule for some inode ino.  A task
> accessing that inode won't have an audit_context until it touches that
> inode.  So there's no loginuid to associate with that action at that
> time.

I don't believe that this is how the current audit code works.  An audit
context is initially set up for a task upon fork/clone via
copy_process-> audit_alloc.  audit_alloc calls audit_filter_task to see
if the task has auditing completely disabled (which must be explicit;
the default is to build a context in the absence of any filters to
disable).  Unless auditing is completely disabled for the task,
audit_alloc creates an audit context for the task, preserves the
loginuid from the parent (with my fix), and sets the syscall auditing
flag.  Subsequently, audit-related information (e.g. paths, inodes,
devices) is captured during syscalls made by the task, and at syscall
exit, audit_syscall_exit calls audit_get_context, which now checks
filters to see if it should mark the context as auditable (and any
earlier calls to audit_log during the syscall e.g. by SELinux will have
already marked it auditable).  If auditable, audit_syscall_exit will
then call audit_log_exit to perform the actual logging.

It has to work in this way for the reason you describe - we don't know
whether the task will trigger any auditable events a priori, so we must
set up an audit context and start capturing information unless the task
is explicitly marked as not requiring any auditing at all.

Stephen Smalley <sds epoch ncsc mil>
National Security Agency

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