Idea
#5913: create (or sponsor) a more secure webbrowser together with mozilla
|
| |
-27
|
|
|
Written by ubuntu_demon the 28 Mar 08 at 11:09.
Category: Security.
Related to:
Nothing/Others.
Status: New
|
|
|
Description
Attachments
No attachments.
Duplicates
Comments
|
vexorian wrote on the 28 Mar 08 at 13:22
|
Ok, let's see.
Firefox3:
* Uses GTK and integrates well into ubuntu.
* Antiphising thing.
* secure connections.
* Tells you if you are using an identified page.
* Allows you to install noscript on it.
So, let's put an already implemented tag on this one.
|
|
ubuntu_demon wrote on the 28 Mar 08 at 13:43
|
Firefox 3 is very nice indeed but it's besides the point.
You should look at the inspiration links before saying "already implemented".
|
|
Eldmannen wrote on the 28 Mar 08 at 14:24
| |
Or just put Firefox under PolicyKit, AppArmor or SE-Linux.
|
|
ubuntu_demon wrote on the 28 Mar 08 at 15:03
|
to Eldmannen :
Putting firefox under PolicyKit,AppArmor or SE-Linux should increase security. Maybe Hardy even does this already. But that's just a small part.
This new secure webbrowser could borrow design ideas from the paper I linked to. You should read the abstract. I'm quoting a small part of the abstract :
[quote]
Our overall design philosophy is to partition the browser into smaller subsystems and make all communication between subsystems simple and explicit. At the core of our design is a small browser kernel that manages the browser subsystems and interposes on all communications between them to enforce our new browser security features.
[/quote]
Please read this comment from slashdot :
http://tech.slashdot.org/comments.pl?sid=502260&cid=22889026 :
[quote]
Web browsers are already complex, and they've been designed without any regard whatsoever for security. It's impossible to go back to static HTML documents by now. So would you prefer that everyone just sticks their head in the sand, and pretends that it'll all go away?
This approach allows for complex browsers to actually become safer, by simplifying them. The browser is broken up into a set of components. Each component runs in a separate process, completely isolated (by the operating system) from the other components. In addition, each component is isolated from the rest of the system using mandatory access controls (SELinux in this case) which prevent the component from doing anything that it doesn't need to do.
The key aspect is that the components only have one way to communicate with each other - a single communications channel which is created by, controlled, and mediated by the kernel process. That means that all interactions between the components are simplified, and can be monitored by the kernel. The kernel itself can be small and simple enough that it's behaviour can be proven correct. The kernel then enforces a security policy.
This approach is known to work - it's similar to the approach used by operating system kernels.
Let's say you break into the rendering component, where the HTML rendering and JavaScript VM reside. You have absolutely no access to the operating system - your only link to the outside world is through the kernel, to the other components. Even if you manage to run native code inside the rendering engine, the operating system won't allow you to access the network, filesystem, or anything else. You only have access to the IPC mechanisms, and even then only to the connection between the rendering component and the kernel.
If your objective is to compromise the operating system through the browser, you can not do that from here. You can't just send a message to the component that handles file access, and get it to load malware onto the system - the kernel will prevent it. Even if you also find a hole in the kernel that allows you to run native code inside the kernel, the kernel doesn't have the ability to access the filesystem either. The filesystem component won't help either - it only has access to a small piece of the filesystem.
If your goal is to steal someone's bank password, you'll still have a tough time of it. The kernel will prevent you from doing anything that doesn't fit within the security policy. Even if you could access a bank password, you're not going to be able to send that information to anyone. If you do have the ability to send that information, you're not going to have access to the passwords.
The idea is not to add complexity - this browser should be no more complex than any other. The idea is to improve security by separating components, isolating them, and verifying that they are not doing anything that they're not supposed to.
It's called "defence in depth" - acknowledging that the system can never be made totally secure, and designing it in such a way that any security breaches won't be able to do any damange, and are able to be tracked for analysis later.
[/quote]
|
|
zooounds wrote on the 28 Mar 08 at 15:53
| |
Firefox is fine. Why reinvent the wheel?
|
|
ubuntu_demon wrote on the 28 Mar 08 at 17:13
|
to zoounds :
Initially this browser would attract :
* users who would probably only use it for online banking
* departments within companies/enterprises who are afraid to allow browsers at all
I'm not talking about reinventing the wheel. With a bit of luck Firefox's rendering engine (Gecko) can be used without much adapation.
Please read the inspiration links to get the idea.
|
Post your comment
|
|
|
