On Mon, 2007-07-16 at 07:41 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> 
> > On Sat, 2007-07-14 at 14:47 -0700, Casey Schaufler wrote:
> > > The patch exceeds the 40k size rule, coming in at about 100k.
> > > I would be happy to send the patch to anyone who has trouble
> > > with the project site. The patch can be found under:
> > > 
> > >     http:/www.schaufler-ca.com/data/smack-0710A-patch.tar
> > 
> > +/*
> > + * In smack sockets are not security policy elements.
> > + * The task associated with the socket is the policy
> > + * element, so point the socket security blob at the
> > + * task blob.
> > + */
> > +static int smack_sk_alloc_security(struct sock *sk, int family, gfp_t
> > priority)
> > +{
> > +   sk->sk_security = current->security;
> > +   return 0;
> > +}
> > 
> > And if the socket outlives the task?
> 
> An error condition that the code isn't handling correctly.
> 
> Unless I'm missing something (happens from time to time) a
> socket that is not associated with a task is not a useful
> entity as it can not be read, written, or reassociated with
> another task. At least, I don't think that there is a way to
> do any of these things. I'm reasonably confident on the first
> two, but less certain about the reassociation bit. I'd be
> happy to learn how my understanding is imperfect should that
> be the case.

The socket can be inherited by a child task or passed via local IPC to
an unrelated task, and then used by those other tasks.  It isn't tied to
the original allocating task's lifecycle in any way, nor is it
guaranteed to only be used by that original allocating task.  It can
exist in zero, one or many tasks' file tables and still be receiving
data, and can go from completely disassociated (i.e. not present in any
tasks' file tables) to being associated.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to