Hello guys,

I want to create a live distro that ideally would only be used on a real PC/laptop - i.e. I would rather nobody were able to fire it up from inside VirtualBox, VMWare or another desktop virtualization solution (I am not bothered about KVM or Xen).

So is it feasible/hard to prevent a live distro from running inside a virtual machine (e.g. by excluding some drivers from the kernel) (or at least hinder it in some way when it's being run from a virtual machine)? If feasible, what are potential ways and pitfalls?

Also is it possible to test for if a live distro is being run from a virtual machine? If I cannot reliably prevent it from being run there, I would like at least to know when someone does it.

Any thoughts would be greatly appreciated.

I doubt you can but if you were to create a distro that had none of the drivers for the few vm's it would bork it. Pitfalls are when one has a system similar to the vm. vm is a software copy of some real hardware in most cases.

You can't test it for the most part. It would have to report and no one likes that.

Almost everyone has VM's and they use them to test out distro's. So doing what you want is pointless.

No, not pointless. This won't be a public distro but a very specialist environment for some of my employees that are on the road with all the applications, VPNs etc necessary for them to co-operate with the office. So the distro 'calling home' and reporting data is not only absolutely fine (it's not up to an employee to 'like', it's a control mechanism) but is one of the purposes of me creating it.

Because of its specialist nature running that in a virtual machine gives me security, control and time-wasting concerns so I would love to be able to prevent that or at least have it reported. The users won't be that technical so I just need to make it hard enough to circumvent running virtual/reporting.

There is no difference between a real and virtual machine.

You have no control by this.

You need better employees or a better NDA or both to fix this.

Control may be in the form of encryption, single use authentication or other protection scheme like a usb security key or parallel key fob.

You could try checking dmidecode's output and /proc/cpuinfo in your boot sequence and if you really want to get hardcore you could make at least the cpuinfo check a kernel patch, it wouldn't be that hard. Put the scripted checks on the initrd and you'll be safe against anything but a determined adversary with at least a little savvy.

Thank you so much, mate. Others also mentioned checking dmidecode.

Over at stackexchange people were kind to point me to:

1) imvirt - a perl script that tries to determine if it's being run from within VM (in Ubuntu repos, maybe in others)

2) virt-what - a similar shell script that is in the repos of all major distros

3) VMWare and Microsoft actually themselves provide a mechanism for their respective products to determine if the program is being run from within VM.

4) redpill technique (using sidt instruction)

While no mechanisms are fool-proof, since my users are not too technical, I'm getting more and more optimistic that I'll achieve what I've set out to create.

Once again, thanks jthill.

jefro, please
- assumption about target audience.
- assumption about the purpose.
- assumption about business model.

And after all these assumptions what advice do you provide?
- incorrect, for the most part

I came to the forums for technical advice and, luckily, a few people were kind enough to help.

0 members found this post helpful.

My technical advice is that your solution will not protect anything. You don't want to listen to that.

If you had followed my original first line you could have solved this for your type of employees. Just remove the support for VM machines off the distro.

Later I gave you other ways to solve this that do actually work in real life for major companies. Yet you didn't want to listen to that.

Further, you believe there is some difference between a real and virtual machine. I can clone off a real machine and get it to work even if you took out the virtual machine drivers because I know I can get it to work. I don't care how you fool with this setup, I can get it working unless you get some advanced ways to protect it.

tl;dr: I suspect anyone who gets close enough to activate this defense has already proven themselves able to bypass it and motivated to do so.

You're worried about someone sophisticated enough to successfully boot a physical partition, and not just that but the currently booted partition, into a virtual machine. Anybody able to answer your questions is probably technical enough to get that working, but I have to ask: what does "won't be that technical" users mean to you that you're worried they can do that?

The biggest problem you're going to have, if you're going to have one at all, won't be with people building VM's your tests can't detect. The first line of attack of anyone who sees you're checking hardware is going to be stripping or subverting those checks. It goes without saying that anyone who can get to that point at all can equally well strip all the rest of your protections unless you get truly hardcore with stuff like making whatever it is you're trying to protect dependent on custom syscalls.

If you're going ahead, one last thing: by "distro" you mean "OS I and my staff will install ourselves on hardware my company owns before handing it to our users", right? Say "yes".

What's the real purpose of this? Why is it important to you that the distro won't run on a VM?

Couldn't someone just copy the disk to an .iso file, modify it to remove that added check, and use the modified disk image in a VM?
Or is this technical enough to no longer be a concern for the target audiance?

The OP already alluded to that in post #3:
the purpose being clear: in his seemingly Dark Age opinion employees are worthless serfs without any rights that must respond to his every beck and call immediately, must be herded unrelentingly and checked on continuously. It's not odd to see though that some people mistakingly seek to solve problems of a completely different order or magnitude through the use of technology. And it doesn't make the technical side of the original question any less interesting.

1 members found this post helpful.

I don't want to discuss the business in detail (competitive advantage ) but I'd like to give a real-world example that is close in spirit to the problem I'm trying to solve:

In the world of online poker there is a lot of supporting software designed to make you play better. Some of this software enables cheating or comes close to that so (I'll use the largest poker room as an example) Pokerstars has a list of software that is allowed to the players and when Pokerstars client is running, it's actively checking the system for any signs of such programs. Some of them are allowed at all times, others (like bots) are banned at all times, yet others are allowed to be installed but cannot be used while Pokerstars client is running.

To this last category belongs a program called SNGWiz - this program parses hand history (which is written to the disk by PS client as text files) and then does equity calculations and advises on optimal play. Pokerstars consider it an unfair advantage for this program to be run in-play but an acceptable training tool if used afterwards. If one gets caught using it in-play, he/she risks suspension, account closure etc. And since PS is the largest room, SNGWiz makers are happy to comply with its wishes so SNGWiz also checks for a running PS client and, if detects it, does not parse hand histories.

I think you guys have figured it out by now how running the 2 programs in separate VMs enables breaking the rules without any risk of detection and without any technical knowledge. Create a shared folder from one VM to the physical machine, get PS client to save hand histories there, share that same folder from the physical machine to the VM no. 2 and get SNGWig to read hand histories from there.

Now if SNGWiz makers wanted to prevent that from happening, they'd need to do the checks I'm interested in - for running from within a VM. Notice that here too, as in my case, the circumvention would be easy - one can use 2 laptops and a shared storage for example. But how many would bother? Absolute majority would just give up therefore preventing a lot of rule breaking.

To unSpawn
You too are making unjustified assumptions about the business model without the knowledge of circumstances. But here is the challenge for you - try explaining to non-technical users the importance of working from read-only media when decrypting sensitive data.

Even if this is a simple game meant for 12 year olds, they could get past this setup in about an hour. You would be better off using other means. As pointed out here a few times, anyone with physical access could take advantage of the hardware and software.