[PATCH] enable /proc/$$/loginuid

[Casey Schaufler]

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