On Wed, Mar 28, 2001 at 08:25:46AM -0500, Alexander Viro wrote:
> <shrug> If you run untrusted binaries - you are screwed. If you run
> them as root - all users on your system are screwed. If your MUA
> (or browser, etc.) can run untrusted code - see above.
But with the new VFS semantics, wouldn't be possible for a MUA to make a
thing like the following:
spawn a process with a private namespace. Here a minimun subset of the
"real" tree (maybe all / except /dev) is mounted readonly. The private /tmp
and /home/user are substituted by read-write directory that are in the
"real" tree /home/user/mua/fakehome and /home/user/mua/faketmp. In this
private namespace, run the "untrusted" binary.
Now the binary can do much less harm than before, or am I missing something?
It have no access to real user data, but can use the system library and
services without changing anything in the system.
Having the read-only flag per vfs-mount is the only kernel-related thing
here, I think; all the rest is simply user-space spice :-).
Have a nice day,
-- Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain) Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 411 132 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/