Desktop apps interoperability

[Stephen Smalley]

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 at tycho.nsa.gov>
National Security Agency