Looks this problem is directly inherited from the way how X works. SELinux will be the right way to solve this problem. Thanks Jose -----Original Message----- From: Phil Betts [mailto:phil_betts@ntlworld.com] Sent: Thursday, March 31, 2005 1:52 AM To: suse-security@suse.com Subject: Re: [suse-security] Firefox invocation allows unintended rootaccess On Wed, 2005-03-30 at 11:27 +0200, Marcus Meissner wrote:

Your remote side can do even more things, like snooping or inserting keyboard input into the main X session.

If you are on the same X Server you have basically full user access.

Of course, but that's not what one expects of a browser whose reputation is built, at least partly, on security. If you invite your trustworthy neighbour in for a drink, you'd be pretty upset if he took control of the TV remote, emptied your fridge and rearranged the furniture!

I do not see this is as a problem, but workin as intended.

Hmm, "as intended" != "correctly" (except perhaps in Redmond). If by "intended", you mean that there should only ever be one instance of firefox per X display, then firefox is broken, because two different users on the _same_ box start independent firefox instances, each with their own set of bookmarks, cookies, extensions etc. Why should this policy be different when running a firefox from a session on a second box? The fact remains that I clicked on a link in an email message as an unprivileged user on my web-facing machine, but found that I had connected to the web as root on a machine that normally only connects to the web for system updates. I would NEVER have connected to the web for any other purpose using my root account (on either box) by choice. If the link I had clicked was actually to a page containing some malicious exploit, I would have been completely stuffed. I can't believe that this is "as intended". Also, regardless of the security implications, if I start a session on a remote box and start firefox, I do this because I want THAT user's set of bookmarks etc., not those of some arbitrary user on a different machine. As it stands, the only way to achieve this is to shut down all prior instances of firefox first, which is neither intuitive, nor desirable. As I mentioned in my original post, I don't know the details of the underlying mechanism, as it involves the interaction of X, ssh and firefox. If you have more knowledge on this, I'll be happy to raise it with the most appropriate party. My guess would be the firefox developers, but for all I know, they may just be using some connect_to_existing_instance() routine in an independently written shared library, which could mean that many apps may be subject to the same problem. Phil -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here