[PATCH] enable /proc/$$/loginuid
Casey Schaufler
casey at schaufler-ca.com
Tue Jan 18 16:55:44 UTC 2005
--- Stephen Smalley <sds at epoch.ncsc.mil> wrote:
> 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.
Okay, so if the task is non-auditable (and hence
has no loginuid because it has no audit context
to contain it) and is made auditable, where will
the audituid come from?
> 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.
While network services are the obvious example,
I have seen "helper programs" that have the same
issue. sudo is the general case of a helper program.
If sudo is exec'd by a process with an unset
loginuid, who is held accountable for the actions
it and its children perform?
And I thought that somewhere near the beginning
of the thread hucking the loginuid about was the
issue.
> > 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.
Doesn't matter if it is possible to mark it
auditable some time in the future. You could
address this issue by making it impossible
to change a task from non-auditable to
auditable. Or, you can make sure that you
always have a loginuid around just in case
the task becomes auditable at some point in
the future. Either works. If you do it the
first way, you'll have to fix it later.
> 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.
You could well be right with regard to the
network issues, it's happened before.
=====
Casey Schaufler
casey at schaufler-ca.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http://info.mail.yahoo.com/mail_250
More information about the Linux-audit
mailing list