Re: [PATCH] enable /proc/$$/loginuid
On Tue, 2005-01-18 at 11:05, Casey Schaufler wrote:
Is it impossible for a task to change from
non-auditable to auditable without setting
the loginuid?
Setting the loginuid is independent of setting filtering rules on the
task, regardless of whether the loginuid is part of the task structure
or part of the audit context.
Is it possible for an auditable task to
perform an auditable action on the behalf
of a non-auditable task? An example here
might be a non-auditable GUI making a
request of the X11 server, or a non-auditable
cluster management daemon using a remote
service via xinetd. In either case the
auditable task needs the loginuid of the
non-auditable task in order to ensure that
auditing is done properly.
Even with a loginuid in the task structure, this would still require a
mechanism to pass the loginuid across network IPC and to verify it in
some manner. That is well beyond the scope of what we are discussing.
I'm sure an evaluation team would get a kick
out of finding that in the audit system
description.
If the task has no audit context, then it was explicitly marked as not
requiring any auditing. And by default, all tasks have audit contexts;
it requires explicit action to mark a task as non-auditable.
While the loginuid may not be directly useful
to a task that never generates audit records
it may be useful for other tasks that are doing
work on that task's behalf.
The audituid of xinetd is rarely interesting.
The audituid of a task that makes a request of
xinetd is usually interesting.
As above, this requires a mechanism to convey and verify loginuids
across network IPC. At that point, you might as well just use the user
identity from the SELinux security context, and leverage ongoing work to
integrate SELinux with IPSEC to implicitly label packets based on IPSEC
security associatio or other work to implement CIPSO-like options for
SELinux.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency