On Mon, 2007-07-16 at 08:32 -0700, Casey Schaufler wrote:
> --- 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.
xinetd?
Look through SELinux policy for all cases where permission is allowed to
a socket with a different domain/type (and even that doesn't tell you
the full story, as multiple tasks/processes may run in the same
domain/type).
> Just curious, what mechanism do you see for associating a socket that
> has no associations with a task?
Task 1 sends a socket S1 to a local IPC socket S2, then closes its own
descriptor to S1. Socket S1 remains alive, can receive traffic. Later
task 2 receives from local IPC socket S2, gets socket S1, then receives
the already queued data from S1.
--
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
