--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> 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.
Great, thank you. I will address all these scenarios, although it may
take a bit to gather the required evidence, or change the code as
necessary. Your claim that the life of the socket isn't tied to that
of the allocating task is correct, however in most cases a socket
spends its entire existence associated with the task that created it
and goes away when that task exits. Even the simple fork case is rare
due to the behavior of multiple processes sharing a socket. In any
case, all possible scenarios need to be addressed.
Just curious, what mechanism do you see for associating a socket that
has no associations with a task?
Casey Schaufler
[EMAIL PROTECTED]
-
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
