Dotan Cohen posted on Sun, 07 Aug 2011 18:06:08 +0300 as excerpted: Dotan Cohen posted on Sun, 07 Aug 2011 18:06:08 +0300 as excerpted: > On Sun, Aug 7, 2011 at 17:34, Duncan <1i5t5.duncan@xxxxxxx> wrote: >> FWIW, there's also an at least theoretical security aspect here, >> particularly for browsing mode. That's part of why the "use with care" >> warning is there. If you use konqueror for online banking, etc, >> ensuring that minimize memory either never, or for file browsing only, >> is selected, and always use a separate window for online banking, so >> it's always a different process and should be more difficult to exploit >> a vuln in from a different site open in another window, as opposed to >> another tab in the same window, or in another window with shared >> processes. >> >> > If you are referring to XSS, then I think that would only apply if each > process were to each have it's own cookie store, which I do not believe > is the case here. Having separate profiles would help in that case. That's probably a more practical worry, but what I had in mind was more the stick data (say disguised as an image, thus binary data) somewhere and exploit a vuln to run it as native code, type thing. Since all memory in a single process is accessible, in theory, one can then read all the data in all other browser sessions in the same process, without resorting to opening files or anything. Of course, the way Linux machines are commonly setup, with all user data readable by whatever apps a user runs as long as it's not run setuid (and that creates other problems for apps that would typically write config and state to a user dir), once one is running native code, it's not difficult to grab whatever info from the disk, etc, except that for automated attacks one must anticipate the layout, etc, which can be harder to do (especially cross-platform) than simply reading all the data already available in the same process. Meanwhile, still talking about security, but no longer about konqueror or browsers specifically, did you know that everything a user types into an X session, including root passwords, etc, AND everything entered in that root session as long as it's running in the same X session, can be sniffed by ANY other process in that X session? Even if said other process is running as SETUID nobody or the like? (Actually, there is apparently one way to capture input exclusively, but it's very seldom used because it's visually disruptive and effectively blocks everything else until its done. Think the MS Windows BSOD, or Red AV warning screens, or whatever, that's the type of exclusive mode and the disruption it causes that we're talking -- IOW, they faced some of the same physical hardware and design issues.) That's the way X was designed. Think about that the next time you're entering your root password or GPG passphrase into an X-based dialog box! That's one of the reasons I'm following qubes, which uses walled off xen sessions, with some interest. (SELinux and nested X can do some of the same stuff as well, but leaves a rather larger attack surface.) For further reading -- I did the suggested experiment (second link) and suggest that you try it too. If the results don't change the way you work in X at least a bit, either you already know all about it, you keep absolutely all private stuff either off the system entirely or in another account you don't access from your "play" account, or you're simply too drugged out to care! The third link explains the Qubes-OS VM partitioning concepts and has a couple diagrams for per-VM network connectivity and data flow between the VMs. http://blogs.pcmag.com/securitywatch/2011/04/why_your_linux_desktop_is_inse.php http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html http://theinvisiblethings.blogspot.com/2011/03/partitioning-my-digital-life-into.html -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.