max wrote:
The question is, how does it know malicious code from what you want
the browser to do?
I don't think it does know malicious code. Heuristic analysis often ends
in false positives. Its based on permission,AFAIK, does it have
permission to read or modify a particular file or directory. The bottom
line is Firefox is difficult to confine.
It's not so much that any program is difficult to confine, it is that
there is no standard for what should be expected or permitted. That is,
before shipping something that tries to guess what some random program
should be able to access, wouldn't it be a good idea to arrange things
in some sort of security level hierarchy first so it doesn't have to
guess? For example, we may know that most programs shouldn't be peeking
under ~/.ssh, but that's an arbitrary bit of information. You don't
know why or what other similarly private bits of information are stored
in random places in your home directory.
Browsers, after the users, are
probably the weakest link in the security chain.
Browsers are a tool that you may want to use to move any file anywhere.
If you can't give them a hint about what should be off limits you
can't expect them to know. But I'd say the weakest link has always been
languages that make it easy to overflow buffers and stacks that are
executable and predictably sized.
> One thing we as users
should do is refuse to use unsafe code.
If it can possibly have a buffer overflow it is all unsafe. The kernel
is unsafe. Pretty much everything you run is unsafe, although some of it
has been scrutinized fairly carefully.
The npviewer.bin application attempted to change the access protection
of memory
(e.g., allocated using malloc). This is a potential security problem.
Applications should not be doing this. Applications are sometimes coded
incorrectly and request this permission. The SELinux Memory Protection
Tests
(http://people.redhat.com/drepper/selinux-mem.html) web page explains
how to
remove this requirement.
Shouldn't compilers get this right by default?
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
