--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> 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?
A rare bird indeed. Actually, a fine example of a system utility
that does exactly what I'm not handling correctly.
> 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).
Looking through the SELinux policy, my dear boy, is exactly
what this whole project is about avoiding.
> > 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.
Thank you. That is a legitimate if perverse and unnatural case.
Clearly the code as written is foolishly optimistic. Updates
forthcoming.
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
