LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Virtualization and Cloud
User Name
Password
Linux - Virtualization and Cloud This forum is for the discussion of all topics relating to Linux Virtualization and Linux Cloud platforms. Xen, KVM, OpenVZ, VirtualBox, VMware, Linux-VServer and all other Linux Virtualization platforms are welcome. OpenStack, CloudStack, ownCloud, Cloud Foundry, Eucalyptus, Nimbus, OpenNebula and all other Linux Cloud platforms are welcome. Note that questions relating solely to non-Linux OS's should be asked in the General forum.

Notices

Reply
 
Search this Thread
Old 11-20-2011, 06:14 AM   #1
klearview
Member
 
Registered: Aug 2006
Location: London
Distribution: Debian, Kubuntu
Posts: 572

Rep: Reputation: 75
Question How feasible is preventing a custom live distro from running inside virtual machine?


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.
 
Old 11-20-2011, 12:06 PM   #2
jefro
Guru
 
Registered: Mar 2008
Posts: 11,098

Rep: Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362
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.
 
Old 11-20-2011, 01:18 PM   #3
klearview
Member
 
Registered: Aug 2006
Location: London
Distribution: Debian, Kubuntu
Posts: 572

Original Poster
Rep: Reputation: 75
Quote:
Originally Posted by jefro View Post
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.
 
Old 11-21-2011, 03:29 PM   #4
jefro
Guru
 
Registered: Mar 2008
Posts: 11,098

Rep: Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362
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.
 
Old 11-21-2011, 05:30 PM   #5
jthill
Member
 
Registered: Mar 2010
Distribution: Arch
Posts: 209

Rep: Reputation: 65
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.
 
Old 11-21-2011, 06:16 PM   #6
klearview
Member
 
Registered: Aug 2006
Location: London
Distribution: Debian, Kubuntu
Posts: 572

Original Poster
Rep: Reputation: 75
Quote:
Originally Posted by jthill View Post
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
Quote:
It would have to report and no one likes that
- assumption about target audience.
Quote:
So doing what you want is pointless
- assumption about the purpose.
Quote:
You need better employees or a better NDA or both to fix this
- assumption about business model.

And after all these assumptions what advice do you provide?
Quote:
You can't test it for the most part
- 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.
Old 11-21-2011, 07:30 PM   #7
jefro
Guru
 
Registered: Mar 2008
Posts: 11,098

Rep: Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362
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.

Last edited by jefro; 11-21-2011 at 07:33 PM.
 
Old 11-21-2011, 08:36 PM   #8
jthill
Member
 
Registered: Mar 2010
Distribution: Arch
Posts: 209

Rep: Reputation: 65
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".
 
Old 11-22-2011, 05:34 AM   #9
ottavio
Member
 
Registered: Nov 2007
Posts: 312

Rep: Reputation: 46
Quote:
Originally Posted by klearview View Post
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).
What's the real purpose of this? Why is it important to you that the distro won't run on a VM?
 
Old 11-22-2011, 06:09 AM   #10
Jenni
Member
 
Registered: Oct 2011
Distribution: Slackware, Fedora
Posts: 158

Rep: Reputation: Disabled
Quote:
Originally Posted by jthill View Post
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.
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?
 
Old 11-22-2011, 06:44 AM   #11
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,988
Blog Entries: 54

Rep: Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743Reputation: 2743
Quote:
Originally Posted by ottavio View Post
What's the real purpose of this? Why is it important to you that the distro won't run on a VM?
The OP already alluded to that in post #3:
Quote:
Originally Posted by klearview View Post
(..) for some of my employees that are on the road (..) 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. (..) running that (..) 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 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.
Old 11-22-2011, 02:24 PM   #12
klearview
Member
 
Registered: Aug 2006
Location: London
Distribution: Debian, Kubuntu
Posts: 572

Original Poster
Rep: Reputation: 75
Quote:
Originally Posted by ottavio View Post
What's the real purpose of this? Why is it important to you that the distro won't run on a VM?
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
Quote:
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
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.
 
Old 11-22-2011, 07:58 PM   #13
jefro
Guru
 
Registered: Mar 2008
Posts: 11,098

Rep: Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362Reputation: 1362
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.
 
  


Reply

Tags
live distro, virtualization


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to install software on WinXP which is inside Virtual Machine Manager 0.8.0 MWH Linux - Software 2 02-19-2011 09:11 AM
running red hat ent 4 on virtual machine inside of Vista tevlone LinuxQuestions.org Member Intro 2 07-26-2009 09:32 PM
Running virtual pc files in a virtual machine in linux ... preferably virtual box biharibong Linux - Software 4 01-21-2009 01:04 PM
Need For A Custom Live Distro? smudge|lala Linux - Distributions 8 10-25-2006 11:08 AM
Best Distro for a Dedicated Arcade Machine? (details inside) dryd kio Linux - Distributions 8 06-30-2006 10:15 PM


All times are GMT -5. The time now is 11:11 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration