One of the defining features of Google's Chrome web browse is its sandboxing feature. You probably won't realise it's there, but from a security point of view, sand-boxing is one of the most impotant factors in browser security, as it severely limits the amount of damage a security hole can do: sure, you've got a hole in the browser, but thanks to sandboxing, you're pretty much locked in - until you break out of the sandbox, of course. Sandboxing on the Windows variant of Chrome was a "complicated affair", says Chromium developer Jeremy Moskovich, but for the Mac version, it's all a bit easier and more straightforward. On Linux, however, it's a mess.
If you browse through the Chromium source code, you'll find the code relating to Windows sandboxing in the /sandbox directory in the source tree, and it consists of about 100 files. For Linux, Moskovich explains, the situation is a mess because there are several different mechanisms available, and each distribution (of course...) ships with a different mechanism - or none at all. "Finding a mechanism that is guaranteed to work on end-user's machines is a challenge," Moskovich adds. The wiki page for Chromium sandboxing on Linux details various mechanisms they're considering - for now, Chrome on Linux does not do sandboxing.
On the Mac OS X side of things, the situation looks a lot brighter. The operating system's sandboxing APIs are "easy and straightforward", and makes use of sandbox_init(), "specifying which resources to block for a specific process. In our case we lock down the process pretty tightly. That means no network access, and very limited or no access to files and Mach ports." After this it gets a bit technical, so to prevent misquoting or errors on my end, I suggest you read the rest of the blog post to get an idea of how it works on Mac OS X.
Again, we see a case where the fragmentation in Linux as a hindrance to companies releasing software for the platform. While Linux' diversity on all levels is a blessing in that it allows for natural selection and competition, it's also a curse for developers trying to write an application that can work well on as many distributions as possible.
I personally tested the recent Mac builds of Chromium on my Intel Mac (PPC is not supported because the V8 JavaScript engine isn't available for PPC), and while it rendered pages just fine, it was still full of bugs and crashed constantly. My guess is that any final release for the Mac is still a way off, with the Linux version taking even longer.
rw:http://www.osnews.com/story/21608/Chrome_Sandboxing_Easy_on_Mac_OS_X_a_Mess_on_Linux
allesgut 于 2009-06-07 20:44:48发表:
ReactOS, the project to create a Windows NT-compatible operating system, has published another news update with some interesting news items. The legal position of the ReactOS Foundation has been strengthened, and now has a VeriSign certificate that might help other open source projects as well, the new ATA driver is more or less complete, and there's some progress in the area of video drivers.
The ReactOS Foundation is the organisation which owns the ReactOS trademarks and logos, and which handles the legal maters around the project. Some good news around the foundation lately: "ReactOS" is now a registered trademark, owned by the foundation, which means they now have a stronger legal position in cases where the ReactOS name is abused. In addition, they now have a digital codesigning certificate from VeriSign, allowing them to sign their releases and preventing fake ones.
There's another major benefit to having such a certificate: as most of you will know, 64bit versions of Windows requires signed drivers, and the ReactOS project think they can help open source projects. "The Foundation is considering setting up a system where projects can apply to have their code signed with the Foundation's certificate, thus working around that particular issue," the project states, "Of course we'd be vetting the code for any issues and any code submitted must conform to the rules they would have followed had they applied for a certificate themselves, but this will at least save them some money along the way."
The UniATA driver is now ready to replace the older SATA driver, enabling better support for ATA controllers. VirtualBOX used to choke on the UniATA driver, but this bug has been temporarily fixed - a definitive fix still needs to be made, since the current one causes a performance penalty (it just disables DMA). "In the future, we'll of course want to actually fix this as not having DMA imposes a performance hit," they explain, "In the mean time, the major blockers with UniATA are now gone and it has been switched over as the default ATA driver for ReactOS."
There's also been some testing in the video driver department, but it's still mostly with old hardware such as Matrox' G100/G400, the ATI Rage II+, and the S3 Trio 64V. "The good news however is that it seems the XP drivers seem to be more reliable than the Windows 2000 drivers, meaning the current kernel side that interfaces with the drivers behaves more like XP. The drivers also provide 2D hardware acceleration," they state, "The bad news is that currently there is still no 3D hardware acceleration. That is going to take a good deal more work on the ReactOS side before we get those benefits."