I had a question earlier, it is tied into this, that one was looking for the proper procedure, this one is looking how to implement. If you need a backstory refer to My first question

I have a local device. I am the only one I want to have "local access". lets call this device charles.local

I want to have it, so when I do addusr bob it spins up a VM bob.charles.local

When bob is at the computer, and logs in, it drops him into his little environment instead of

I know how to spin up a VM, a full instance with an OS, not what I am looking to do, but I can make mods where needed, I know how to manage a local computer using linux, I know how to fdisk create loop dev's.

  1. Would init be able to handle the login process that I am aiming for, so when the login screen pops up, and bob logs in, it automatically drops him in the VM, or would I need a separate login server, such as kerberus?
  2. Is it possible to spin up a VM with only 1 user, no additional user to be added and make it look like bob just logged into the computer like normal.
  3. I was able to track down, skel, login, logout, adduser, deluser, passwd, shadow, config files, would I have to modify the initd config? are there any other configs I need to get this ball running?
    1. Do I need any other specific software outside of a VMM?

I am trying to get a local device setup, so that a class can login to a machine, and have 0 access to the actual machine so they can tinker with root without disrupting the other students, and with minimal input from them... Basically, the only input to the local machine they can do is their user name and password. Everything else would be handled in their environment.


I don't have enough points to comment, but there's some chance this might also answer your question.

If I'm understanding you correctly, you want to allow local user logins, and once a user is logged in, spin up a new VM from scratch and auto-configure a user session of the same name? That could get pretty hair very quickly, if I'm understanding your requirement correctly.

How about this instead, which sounds like your intended goal--a "kiosk" mode except where the user has unlimited local power even to destroy the whole OS, but it's easily reset. (In this case, automatically.) The only difference, I think, is that there are no specific individual user sessions involved, because for this idea to work, individual user sessions aren't actually needed, and in fact complicate things. (But if individual user sessions ARE a requirement, then at least this solution could still get you started in the right direction. Think "read-only, immutable Base VM disk image that is accessible by all users, but each user has their own VM definition file and read/write differencing disk, both of which get deleted and restored with each login.)

First some quick definitions:

  • "Host", or "Machine": The physical machine. Might be running Windows, MacOS, or Linux, it shouldn't matter too much--each of those can be configured this way, although it's not always obvious how to intercept logouts and shutdowns in any of them. (I know both can be done in Windows and Linux, and strongly suspect in MacOS. All of them can also be configured for auto-login on startup.)

  • "VM", "virtual machine", or "guest": A virtual machine running on a host machine. By the sounds of it, you want this to be Linux, but it could just as easily be Windows, except for potential licensing headaches. (E.g. if a user screws up the licensing, that screw-up persists even if the OS itself starts completely over from a checkpoint.)

Every host machine will have a single "user" session, and within that user session, a single, transparent guest session. The user will only see or necessarily know of the existence of, the guest session. (But the security of the host session shouldn't--and doesn't have to--rely on that obscurity.)

General steps:

  1. Set up the host machine to automatically log into one locked-down user account upon startup, e.g. "vmuser". Deactivate session timeout/lock, and screensaver. (Screen power off OK but without locking the session.)

  2. Create a VM for that user session, with an immutable disk and a differencing file, or a snapshot to roll back to.

  3. Upon initial host login (at startup), have a login script launch a VM session in full screen mode (with an obscure redefined "host" key. e.g. scroll lock). That script should wait until the VM powers down, because it will have more work to do later.

  4. That VM also then auto-logs-in to root, or a user with admin rights.

  5. Guest logout script: Shut down the whole VM.

  6. Once the VM shuts down, your login script resumes. It rolls the back to a predefined snapshot. If the host user session is not also ending, that script should then start the VM back up again. (It then auto-logs in again and your back and rolling with a fresh new session.)

  7. Host logout script: You'll need to communicate with the login script in one of myriad possible ways, to either abort it, or tell it to not start the VM back up after doing its rollback stuff. Either way, what you want to happen is to power off the VM (even a "hard" power off is acceptable). Rolls the VM back to snapshot. Then either have the host auto-logs back in again (which would require a service or daemon watching and would result in a clean restored VM coming back up), or power-down the host machine completely.

  8. If the user shuts down the host, the same thing happens as logging out (because the user session first logs out), except you'd want to communicate with that script to preempt logging back in, or shutting down the host (redundantly).

  9. Whenever the host user session logs in (which ironically may be more reliable in terms of timing than doing this on host startup), the login script should always roll the VM back to snapshot before starting it up (or at least check to make sure), just in case it wasn't cleanly shut down last time. Or if you REALLY want to be robust, a host machine startup script could do all the cleanup it needs to--deleting any files potentially used for inter-process communication, rolling back the VM just in case, etc.--all the while the login script, if inevitably initiated while all this is going on, waits until that process is done before proceeding.

This way, the user can do whatever they want in the VM, including "rm -rf /", and a VM shutdown, a logout of the host user session, or a host reboot will restore it automagically. As long as the host user session is reasonably well locked down and secure, and the immutable VM disk not user-deletable (which would be a good reason to set it up that way rather than snapshots), then it would be REALLY hard for users to screw the system up, even if they broke out of the VM. (That said, anyone with physical access can compromise a computer. And it should go without saying--therefore I wish it didn't need to be said--that any exploits to the host OS could also compromise your solution. But at least exploits to the guest are mostly moot in terms of permanent guest OS damage, as it gets rolled-back/reset anyway.)

I'm pretty confident something along these lines is possible, reasonably close to what was outlined--because I know each of the individual steps are possible and have done many of them myself.

Your general need is something along the idea of "kiosk-mode", which you can Google for. Granted, kiosk modes usually also involve locking down the user's experience, which is the opposite of what you want, but there may be some ideas out there that get you close, or similar to this but with different tech (e.g. containers).

Good luck!

| improve this answer | |
  • WOW. You got pretty darn close! I am so thankful you could read through my rambling. I am looking more along the line of permanent user environment so the students have their own VM, that they can tinker with. That they can remote into, see a login page, and when they login, it drops them in their environment. does that make sense? – Charles Wilson Sep 5 '18 at 3:31
  • I think so. I updated my response to include a general (less detailed) way to allow individual user logins. I'm still pretty sure that would be possible. The part about auto-creating users in the guest OS though, that could be tricky. What you might be able to do, is host a single guest OS image on a network location, and manually update that as needed to add users. Or even tie into ActiveDirectory, LDAP, etc. (But not when anyone else is also using it as a base image!) Then individual users can log in to the guest OSes using their own credentials. – Jim Sep 5 '18 at 3:38
  • The individual users would need to be configured with their own read/write differencing disk images, similar to how the answer describes. The host OS could be configured with just one locked-down user as describe in the answer (requiring only one login--into the guest OS), or with their own individual user sessions also tied to AD/LDAP/etc. (Which would require two logins, unless you could figure out how to get the VM to use the host's login ala "single sign-on", but that idea feels like a fundamental violation of security that VM vendors would shun...I don't know anything on that front.) – Jim Sep 5 '18 at 3:43
  • 1
    You are amazing Jim, gave me a solid foundation to tinker off of. I appreciate you – Charles Wilson Sep 5 '18 at 3:44

Not the answer you're looking for? Browse other questions tagged or ask your own question.