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.
