On Mon, 2005-03-28 at 17:47 +0200, Tom wrote: > Not so sure about the pointlessness here. The point is that it makes it > more difficult to leverage exploits. Maybe I can break into Firefox, > but with that in place I can't jump from there to mplayer by forcing it > to play something I know will break it. I'm not sure I understand your intent. There are two scenarios: 1) mplayer directly launched by firefox. As the attacker already has control of the firefox process, the only possible benefit of compromising a mplayer process launched by firefox is if it has further permissions needed to achieve his end goal. And how you prevent such abuse of a directly launched mplayer is unclear, e.g. do you intend firefox to engage in an IPC interaction with a process in the desktop session to ask for the downloaded file to be relabeled prior to launching mplayer on it? 2) mplayer launched by something other than firefox, e.g. user shell, nautilus, after prior download of content via firefox. At this point, the user has explicitly selected the downloaded file, thus expressing his intent (modulo any subversion of the user process itself, which is a separate issue), and can hopefully be trusted not to open files that he didn't download explicitly (if not, then how can he be trusted to make decisions about relabeling)? Hence, in this scenario, the relabeling doesn't express the user intent any better than the selection by the user of the downloaded file. Naturally, what you really want there is a trusted path mechanism. -- Stephen Smalley <sds@xxxxxxxxxxxxx> National Security Agency
