Alan Cox wrote:So someone finds a way to break into the jailed process.
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:Pardon. Its equally ineffectual. It might take someone a week longer to
* Considerably safer against root users in cage
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 toThat doesn't do name lookup, character set translation, or time (and a
implement except in a daemon that starts its life as root. Now the
same techniques can be used by any process.
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.