Right, because if running the Flash plugin because it's proprietary is bad then running the non-open-source and proprietary Parallels system is accepted. I think I see the logic there. :)
Dante Lanznaster wrote: > there's 2 approaches for this. > > 1) Use a virtual machine > > 2) Use OS virtualization stuff like Parallels > > > > On Thu, Nov 27, 2008 at 12:08 PM, Michael Sokolov > <[email protected] <mailto:[email protected]>> wrote: > > Dante Lanznaster <[email protected] <mailto:[email protected]>> wrote: > > > Believe me, you'll want a x86 platform to run youtube videos... > (it needs > > the flash plugin) > > > > FLASH! you know, that one from Adobe! > > I've already figured as much. > > Has anyone already come up with a mechanism to run these f***ing closed > source binary plugins in some kind of severely restricted "jail" > environment where the untrusted code is blocked from accessing any > system resources which aren't on a pre-approved list? I'm thinking > along the lines of something like this: a process makes a special system > call which tells the kernel "I'm about to run untrusted binary code for > which we have no source", and from that point on the kernel sets some > special flag marking the process as untrusted. The untrusted process is > then prohibited from using any system calls which aren't on a > pre-approved list, from accessing any files outside a pre-approved list, > and from accessing any network resources outside of another pre-approved > list. Has anyone already created something like this, or am I going to > have to hire someone with NSA-level security experience to custom-design > it for me from scratch? > > Developing this idea further, if I want to treat all closed source > binary x86 code as untrusted and dangerous (which is indeed my security > policy) and run it only in special restricted "jail" environments like > I've described, it probably wouldn't be that much extra effort to make > this "jail" environment in the form of a software-based x86 instruction > set emulator running on a machine whose native architecture could be > completely different... > > MS > _______________________________________________ > LinuxUsers mailing list > [email protected] <mailto:[email protected]> > http://socallinux.org/cgi-bin/mailman/listinfo/linuxusers > > > > ------------------------------------------------------------------------ > > _______________________________________________ > LinuxUsers mailing list > [email protected] > http://socallinux.org/cgi-bin/mailman/listinfo/linuxusers
