If that's the bodyguard Mac vs PC ad... (can't check here)
I think as a whole those ads suck. I think they are overly inflammatory and full of hyperbole, and remind me and evoke the same emotions in me as many attack ads during a political campaign.
But I have to say, the one with the bodyguard representing UAC... that one is actually pretty damn funny.
I can't speak to the actual answer, but I would suspect if this is true the current thread would be elevated. Threads in Windows have their own security descriptors, so can run with different privileges than other threads in that process.
But I still argue that reducing the amount of code executed, as much as possible, to things controlled by the OS distributor is a good thing for security.
As opposed to Vista, which will let you install applications without root?
I strongly suspect (though I don't have Vista so can't verify) that this won't let you install things if you don't have admin privileges already. So it's really no different, except that RPMs don't traditionally (can't?) load kernel modules.
I thought about this before, and I think that Windows might be filled with so much spaghetti code and hacks that it is better not to know the crazy inner workings.
I bet they at least don't have a preprocessor macrocurrent that caused at least one kernel newbie 20 minutes of frustration trying to figure out why in the hell the line int current; was causing compilation errors.
What the earlier commentators miss is that journalists do have shield-laws to protect them for divulging their sources. This is so that the first amendment means something. This allows mud-racking journalists (few and far between in MSM) to protect their sources. For example, remember Mark Felt (aka. Deep Throat), the guy who brought down Nixon? Because he was talking to journalists, he knew that Woodward and Bernstein could refuse to talk under subpoena.
Tell that to Judith Miller, who was threatened with criminal contempt for doing what you say is protected.
Finally, how long is Josh going to be locked up? Are we going to allow an indefinite sentence? (Which in the U.S. is supposed to be illegal?).
And the various licenses for Vista are the first ones to mention virtualization.
And at the same time, the older licenses did nothing to prohibit it. The OS X license leave no room for doubt that it is a license violation to virtualize OS X on non-Apple hardware, and even virtualizing on Mac hardware is slightly unclear if it would be allowed.
[Oops, looks like I missed closing my tag last post. Sorry about that.]
You need to study your copyright law better. 17 USC 117 explicitly allows copies that are made of a computer program that are required for using the program. In addition, I think you would have a very strong argument (at least if you were not reusing a license, and especially if you were virtualizing on a Mac) for fair use.
#1. Windows sells its own virtualization software. To prohibit others from virtualizing -- or really even to give the impression of making it purposely difficult for others -- would invite an antitrust lawsuit
#2. The Windows licenses don't prohibit virtualization.
#3. The licenses for Vista Ultimate and Business explicitly ALLOW virtualization.
That would be the joy of contributory copyright infringement
Listen closely. Breaking the EULA != copyright infringement, and thus they can't be engaged in contribuatory copyright infringement.
VMWare and Parallels would likely not have any legal repercussions from providing instructions for running OS X, but it would probably piss off Apple enough that the ill will would bring more negative results than there would be positive ones from the increased use of the software.
The headline and summary are somewhat stupid for this story.
The patent mentions "school" exactly once, and is using it to just provide an example as to where it could be used. ("The policy may be directed to a single computer and thereby a single user or subscriber. Alternately, the policy may extend to a group of computers and correspondingly to a common owner, for example, a business or school.")
You're still using the term "operating system" which I just said doesn't actually mean anything.
True. I'm not sure exactly what I was thinking, if I meant that to refer to "OS" or "kernel".
Are the user-level servers part of the kernel? No. Are Windows device drivers part of the kernel? Pre-Vista, yes. Vista's user mode framework? No.
Why the distinction? The protection level the code is executing in? Drivers running in ring 0 are part of the kernel, drivers in user-space aren't?
If that's the case, are (were) DOS programs part of the MS-DOS kernel? In real mode, there's no concept of kernel vs. user-space, so effectively they're both running in ring 0. (In reality there is no such thing as ring 0 in real mode, so this isn't true.)
(FWIW, I wouldn't count drivers as part of the kernel.)
This is the webpage for the Cyber Security Lab. I don't see anything about this on there, but a Google search for Proactive Worm Containment brings up this presentation.
There can be absolutely no doubt about what code belongs to the kernel and what code belongs to userspace and what difference that makes.
Really?
In a microkernel, are the user-level servers part of the OS? In Windows, are the device drivers part of the OS? What if they are built with the user mode framework and run in ring 3?
I'm going to steal a definition of an operating system from Dawson Engler:
we define the operating system as any piece of software that the application cannot either change or avoid. User-level device drivers, privileged servers, and kernels are all included by this definition.
I'm not MS legal, but you'd have one installation of Vista that you'd use multiple ways, and you'd never be using it both ways at the same time. I'd say that's probably okay. It at least probably wouldn't be worth MS's bother to try to stop you.
VMware and VirtualPC are detectable because pre-hardware virtualization x86 was too slow to virtualize completely. The problem comes up because the x86 has security-sensitive but non-privileged instructions. The classic example is SIDT. This instruction stores the contents of the interrupt descriptor register (that gives the processor the address of the interrupt service routine to run when an interrupt arrives) into a given location in memory; it can be used in user mode. However, an OS needs to be able to issue the LIDT instruction that sets the IDT so that it points to its ISR. Now, when running in a VM, the hypervisor needs to somehow trap (at least conceptually) when the guest OS issues the LIDT instruction, because the IDT needs to point to the hypervisor's ISR instead of the guest OS's. Instead, the hypervisor records what the guest OS tried to set it to, and emulates calls to in when interrupts arrive in the future. But now the IDT contents are different what the OS thinks they should be -- so issuing the LIDT in kernel space then the SIDT instruction (probably in either kernel or user space, but to be safe in user space) and comparing if the IDT is what the OS thinks it should be indicates if you're in a VMWare- or VirtualPC-style VM. (If they differ, you're in a VM.)
Now, what would be required to change this? VMWare accomplishes virtualization by binary rewriting: they examine the stream of instructions that are about to execute, and change it so that they will operate appropriately. Instructions that change the priviledged state of the machine (such as LIDT) are essentially translated into system calls, because the guest OS is now running in user space instead of kernel space. However, they only do this binary translation for the kernel. They don't do it for any user applications that run. The reason is that it's somewhat slow; it's why running a system in VMWare is slower than running it on the bare metal. Imagine if they also had to do binary translation on user space processes. But that's exactly what they would have to do if they wanted to protect against a user application issuing a SIDT instruction to read the privileged state.
So it's not so much that it's detectable on purpose as it is they decided (pretty much completely rightly) that the performance hit that would be required to protect aginst this would be far, far, FAR worse than allowing detectability.
It's for this reason that I don't think there is ANY x86 virtualization program that both works on pre-VT/Pacifica hardware (that avoids this issue) and is undetectable. (I bet that even Xen with a paravirtualized Linux could be detected via this method.) The closest you get is Bochs, but that's complete emulation, not virtualization. (Because that's almost what you need if you want to completely virtualize x86 before direct HW support.) In other words, by your definition, there AREN'T any good virtualization software products for year-old x86 chips.
(Also, another interesting point; VMWare has a paper out that demonstrates that their binary rewriting is actually about an order of magnitude faster than hardware virtualization on some tasks for the first P4s that supported it.)
Microsoft, on the other hand, says you only have Vista rights if Vista is the primary OS at that time.
While the EULA isn't really clear, each time this issue has come up there seems to be somewhat of a consensus that this is wrong. The Vista EULA probably doesn't prohibit you from running inside a VM; it just says that if you do that, that eats a license. So if you have Vista home, you can't install that as both your primary OS and on a VM.
What would you define as good virtualization software then? VMWare is considered for good reason the leader in x86 virtualization right now, and it's easy to detect that you're running in VMWare.
In fact, the only VM software that it's not easy to detect are ones that are using the almost brand-new VT/Pacifica hardware virtualization support.
And take another look at the http://it.slashdot.org/article.pl?sid=07/02/07/213 7233 article - my guess is it's been changed because what you wrote above "Could children with a $100 laptop end up with a better security infrastructure than executives using $5000 laptops powered by Vista?" is verbatim from the summary. Maybe I misread what you wrote.
Oh, oops. I miswrote what I wrote.;-)
I intended to say 'why not say "Could children with a $100 laptop end up with a better security infrastructure than executives using $5000 laptops powered by Linux?"', since the article is also hard on Unix-type security. (Though to be fair Vista makes more sense, but it just seems like another typical/. MS slam to me, which also get old after a while.)
Do I think this thread will make a difference? I very much doubt it. Maybe over time if enough people pester those in charge to drop the dumb comments...
I was more trying to illustrate how obnoxious it is to end comments with an annoying question.
Slashdot Mirror
If that's the bodyguard Mac vs PC ad... (can't check here)
I think as a whole those ads suck. I think they are overly inflammatory and full of hyperbole, and remind me and evoke the same emotions in me as many attack ads during a political campaign.
But I have to say, the one with the bodyguard representing UAC... that one is actually pretty damn funny.
Then what is elevated?
I can't speak to the actual answer, but I would suspect if this is true the current thread would be elevated. Threads in Windows have their own security descriptors, so can run with different privileges than other threads in that process.
But I still argue that reducing the amount of code executed, as much as possible, to things controlled by the OS distributor is a good thing for security.
Even if that distributor is MS?
However, applications developers seem to be in love with the registry, despite the fact that it really offers them no benefits whatsoever.
To be fair, it does offer a hierarchical and transactional data store. Which you don't get nearly as easily from flat files.
The registry has a lot of drawbacks, but it wasn't that unreasonable an idea actually.
As opposed to Vista, which will let you install applications without root?
I strongly suspect (though I don't have Vista so can't verify) that this won't let you install things if you don't have admin privileges already. So it's really no different, except that RPMs don't traditionally (can't?) load kernel modules.
... you can use the acronym STAMP.
I thought about this before, and I think that Windows might be filled with so much spaghetti code and hacks that it is better not to know the crazy inner workings.
I bet they at least don't have a preprocessor macro current that caused at least one kernel newbie 20 minutes of frustration trying to figure out why in the hell the line int current; was causing compilation errors.
What the earlier commentators miss is that journalists do have shield-laws to protect them for divulging their sources. This is so that the first amendment means something. This allows mud-racking journalists (few and far between in MSM) to protect their sources. For example, remember Mark Felt (aka. Deep Throat), the guy who brought down Nixon? Because he was talking to journalists, he knew that Woodward and Bernstein could refuse to talk under subpoena.
Tell that to Judith Miller, who was threatened with criminal contempt for doing what you say is protected.
Finally, how long is Josh going to be locked up? Are we going to allow an indefinite sentence? (Which in the U.S. is supposed to be illegal?).
Why illegal?
But criminal contempt can carry life in prision.
And the various licenses for Vista are the first ones to mention virtualization.
And at the same time, the older licenses did nothing to prohibit it. The OS X license leave no room for doubt that it is a license violation to virtualize OS X on non-Apple hardware, and even virtualizing on Mac hardware is slightly unclear if it would be allowed.
[Oops, looks like I missed closing my tag last post. Sorry about that.]
You need to study your copyright law better. 17 USC 117 explicitly allows copies that are made of a computer program that are required for using the program. In addition, I think you would have a very strong argument (at least if you were not reusing a license, and especially if you were virtualizing on a Mac) for fair use.
#1. Windows sells its own virtualization software. To prohibit others from virtualizing -- or really even to give the impression of making it purposely difficult for others -- would invite an antitrust lawsuit
#2. The Windows licenses don't prohibit virtualization.
#3. The licenses for Vista Ultimate and Business explicitly ALLOW virtualization.
That would be the joy of contributory copyright infringement
Listen closely. Breaking the EULA != copyright infringement, and thus they can't be engaged in contribuatory copyright infringement.
VMWare and Parallels would likely not have any legal repercussions from providing instructions for running OS X, but it would probably piss off Apple enough that the ill will would bring more negative results than there would be positive ones from the increased use of the software.
The headline and summary are somewhat stupid for this story.
The patent mentions "school" exactly once, and is using it to just provide an example as to where it could be used. ("The policy may be directed to a single computer and thereby a single user or subscriber. Alternately, the policy may extend to a group of computers and correspondingly to a common owner, for example, a business or school.")
You're still using the term "operating system" which I just said doesn't actually mean anything.
True. I'm not sure exactly what I was thinking, if I meant that to refer to "OS" or "kernel".
Are the user-level servers part of the kernel? No. Are Windows device drivers part of the kernel? Pre-Vista, yes. Vista's user mode framework? No.
Why the distinction? The protection level the code is executing in? Drivers running in ring 0 are part of the kernel, drivers in user-space aren't?
If that's the case, are (were) DOS programs part of the MS-DOS kernel? In real mode, there's no concept of kernel vs. user-space, so effectively they're both running in ring 0. (In reality there is no such thing as ring 0 in real mode, so this isn't true.)
(FWIW, I wouldn't count drivers as part of the kernel.)
There is a presentation about it, but it doesn't go into any more detail about the detection occurs than the article.
Is there ever a magic bullet though?
What fix has there ever been that would totally stop a class of attacks in their tracks? The only one I can come up with is typesafe languages.
I wish the article didn't pretty much suck...
This is the webpage for the Cyber Security Lab. I don't see anything about this on there, but a Google search for Proactive Worm Containment brings up this presentation.
There can be absolutely no doubt about what code belongs to the kernel and what code belongs to userspace and what difference that makes.
Really?
In a microkernel, are the user-level servers part of the OS? In Windows, are the device drivers part of the OS? What if they are built with the user mode framework and run in ring 3?
I'm going to steal a definition of an operating system from Dawson Engler:
we define the operating system as any piece of software that the application cannot either change or avoid. User-level device drivers, privileged servers, and kernels are all included by this definition.
I'm not MS legal, but you'd have one installation of Vista that you'd use multiple ways, and you'd never be using it both ways at the same time. I'd say that's probably okay. It at least probably wouldn't be worth MS's bother to try to stop you.
VMware and VirtualPC are detectable because pre-hardware virtualization x86 was too slow to virtualize completely. The problem comes up because the x86 has security-sensitive but non-privileged instructions. The classic example is SIDT. This instruction stores the contents of the interrupt descriptor register (that gives the processor the address of the interrupt service routine to run when an interrupt arrives) into a given location in memory; it can be used in user mode. However, an OS needs to be able to issue the LIDT instruction that sets the IDT so that it points to its ISR. Now, when running in a VM, the hypervisor needs to somehow trap (at least conceptually) when the guest OS issues the LIDT instruction, because the IDT needs to point to the hypervisor's ISR instead of the guest OS's. Instead, the hypervisor records what the guest OS tried to set it to, and emulates calls to in when interrupts arrive in the future. But now the IDT contents are different what the OS thinks they should be -- so issuing the LIDT in kernel space then the SIDT instruction (probably in either kernel or user space, but to be safe in user space) and comparing if the IDT is what the OS thinks it should be indicates if you're in a VMWare- or VirtualPC-style VM. (If they differ, you're in a VM.)
Now, what would be required to change this? VMWare accomplishes virtualization by binary rewriting: they examine the stream of instructions that are about to execute, and change it so that they will operate appropriately. Instructions that change the priviledged state of the machine (such as LIDT) are essentially translated into system calls, because the guest OS is now running in user space instead of kernel space. However, they only do this binary translation for the kernel. They don't do it for any user applications that run. The reason is that it's somewhat slow; it's why running a system in VMWare is slower than running it on the bare metal. Imagine if they also had to do binary translation on user space processes. But that's exactly what they would have to do if they wanted to protect against a user application issuing a SIDT instruction to read the privileged state.
So it's not so much that it's detectable on purpose as it is they decided (pretty much completely rightly) that the performance hit that would be required to protect aginst this would be far, far, FAR worse than allowing detectability.
It's for this reason that I don't think there is ANY x86 virtualization program that both works on pre-VT/Pacifica hardware (that avoids this issue) and is undetectable. (I bet that even Xen with a paravirtualized Linux could be detected via this method.) The closest you get is Bochs, but that's complete emulation, not virtualization. (Because that's almost what you need if you want to completely virtualize x86 before direct HW support.) In other words, by your definition, there AREN'T any good virtualization software products for year-old x86 chips.
(Also, another interesting point; VMWare has a paper out that demonstrates that their binary rewriting is actually about an order of magnitude faster than hardware virtualization on some tasks for the first P4s that supported it.)
What else is new thought? Slashdot is just a Fark for linux geeks.
I think Fark has fewer dupes (at least percentagewise) and outright wrong stories.
Microsoft, on the other hand, says you only have Vista rights if Vista is the primary OS at that time.
While the EULA isn't really clear, each time this issue has come up there seems to be somewhat of a consensus that this is wrong. The Vista EULA probably doesn't prohibit you from running inside a VM; it just says that if you do that, that eats a license. So if you have Vista home, you can't install that as both your primary OS and on a VM.
What would you define as good virtualization software then? VMWare is considered for good reason the leader in x86 virtualization right now, and it's easy to detect that you're running in VMWare.
In fact, the only VM software that it's not easy to detect are ones that are using the almost brand-new VT/Pacifica hardware virtualization support.
And take another look at the http://it.slashdot.org/article.pl?sid=07/02/07/213 7233 article - my guess is it's been changed because what you wrote above "Could children with a $100 laptop end up with a better security infrastructure than executives using $5000 laptops powered by Vista?" is verbatim from the summary. Maybe I misread what you wrote.
;-)
/. MS slam to me, which also get old after a while.)
Oh, oops. I miswrote what I wrote.
I intended to say 'why not say "Could children with a $100 laptop end up with a better security infrastructure than executives using $5000 laptops powered by Linux?"', since the article is also hard on Unix-type security. (Though to be fair Vista makes more sense, but it just seems like another typical
Do I think this thread will make a difference? I very much doubt it. Maybe over time if enough people pester those in charge to drop the dumb comments...
I was more trying to illustrate how obnoxious it is to end comments with an annoying question.