Re: [RFC] relinquish_fs() syscall

[Mitchell Blank Jr]

Alan Cox wrote:
> A priviledged user can ioperm/iopl their way out.

OK, good point, at least on i386/x86_64.  So before jailing itself a task
will have to take CAP_SYS_RAWIO out of its permitted set.  That shouldn't
be too bad of a restriction for most programs to live with.

> On Llu, 2004-11-29 at 11:43, Mitchell Blank Jr wrote:
> > This has several benefits:
> > 
> >  * Considerably safer against root users in cage
> 
> Pardon. Its equally ineffectual. It might take someone a week longer to
> write the exploit but an hour after that its no different.

OK, could you please describe other attacks against it then?

> >    This is a big deal for privilege separation; currently it's hard to
> >    implement except in a daemon that starts its life as root.  Now the
> >    same techniques can be used by any process.
> 
> That doesn't do name lookup, character set translation, or time (and a
> few other things).

Alan - have you looked at privsep implementation in, say, opensshd.  The
way privsep works is that you have two processes communicating over a
UNIX domain socket.  One then jails itself and handles all the hairy
untrusted data.  The unjailed process handles requests from inside as
needed.  So if the program needs to do DNS lookups then your privsep
protocol would include a primitive for doing that.

Some information on openssh privsep, including the USENIX paper:
  http://www.citi.umich.edu/u/provos/ssh/privsep.html

Frankly, if a program is touching lots of untrusted data AND it also needs
lots of external stuff then it's a perfect candidate for privsep.

> >    Imagine, for example, a jpeg decoder that after opening its input and
> >    output files called relinquish_fs().  Now if the decoder has a flaw and
> 
> Imagine a jpeg decoder using an SELinux policy. 

SELinux is great but it's a pretty orthoginal issue.  There's no reason the
two can't coexist.

-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/