On Thu, 2007-07-19 at 08:26 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, 2007-07-18 at 18:15 -0700, Casey Schaufler wrote:
> > > --- Joshua Brindle <[EMAIL PROTECTED]> wrote:
> > > 
> > > > Casey Schaufler wrote:
> > > > > ...     
> > > > >
> > > > > I do have a hackish newsmack command, which I should probably include.
> > > > > All it does is write the new label to /proc/self/attr/current and
> > > > > exec the desired program. That's not good enough for a production
> > > > > system because of the well known pty, tty, and open files issues,
> > > > > but fine for development purposes.
> > > > >  
> > > > 
> > > > Right, I'd like to see how you solve those problems :)
> > > 
> > > Me too. Especially with devpts "out of bounds". I have some ideas,
> > > but I don't know whether they're good ones yet.
> > 
> > I'm not sure what you mean by the above.
> 
> There was discussion some time back in which changes to devpts
> had been suggested but rejected due to the firm stand of the devpts
> maintainers. I can dredge the thread up if it's important.

Not sure which thread that was.

> > In selinux, we label the ptys
> > with a label derived from the allocating task at creation time (handled
> > by d_instantiate hook),
> 
> So far so good ...
> 
> > and then let userspace relabel them as
> > appropriate based for the user session label for login/sshd and newrole.
> 
> ... which may be the end solution. Another way to do it is to
> associate a label with the connection between the pseudo devices
> rather than the endpoints. That might require devpts changes.
> If there is a kernel based solution, and I don't have one in hand
> yet, it would be slick.

There is the known problem with newrole relabeling of the pty leaving
the master end unchanged.

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