Messages in this thread | | | Subject | Re: [RFC] relinquish_fs() syscall | From | Alan Cox <> | Date | Mon, 29 Nov 2004 11:51:29 +0000 |
| |
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.
> Normal chroot's are trivial for privileged users to break out of - > these tasks don't work in the namespace. You can't create a directory > to do the "chroot foo; cd ../../..; chroot ." trick. You can't > create device nodes or mount /proc anywhere (I added an extra check > to do_mount() that even prevents a mount on top of '/')
A priviledged user can ioperm/iopl their way out.
> 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).
> 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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |