Re: [RFC] relinquish_fs() syscall

[Alan Cox]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/