lkml.org 
[lkml]   [2004]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] relinquish_fs() syscall
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.048 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site