Allowing Students to Run exe as part of their programming course. Solution needed

[noah]

Hi

 

We have just been asked to setup a way of students running .exe files as part of their programming course in visual basic.

 

Any suggestions on how we might do this, so as to not to pose a security risk to the network?

 

We currently run Ranger on our network, server 2012 and windows 7 clients.

 

Help, much appreciated.

 

Noah

[TheScarfedOne]

Virtual machines is how Ive managed this one. For us, we have built a Linux VM based on SLAX, which has loads of great programming utilities in it. In our case it was Python and Scratch among others. I read you need VB, but Im sure there must be some utils for it - or use an XP VM. Weve used VirtualBox, which has no network connection, but uses and allows access to the mapped U:\ (Home Drive) of the logged on user. Hey presto - file access and storage. They can write and run the code in the VM, save to their area, but not run the code from the normal network. I hope this makes sense.

[digone52]

I had this issue before the summer holiday. Personally, I don't want pupils running their .exe's on the domain in any shape or form. I considered running virtual machine images on the local PC with the vm images coming from the network, allowing the user to roam, but this was a dead end for a number of reasons.

 

Really pleased with the solution - a Windows 2008 R2 box running terminal services and Visual Studio, with 12 cores and 24GB of RAM, all data held locally on the server, and the server is a standalone. Only Comp Sci pupils can access the box as they can only run the RDP client by group membership. FSRM on the domain prevents them from copying executables to their home dirs, but using RDP they have access to local drive letters and printers, and can even use a memory stick to take home their work. NOTE I believe that a 2012 terminal server needs to sit in a domain, so I think you need 2008 R2, at least in the way we have configured it.

 

With this spec, we've had 20 or 30 concurrent users, no issues, no speed problems, everyone happy.

Edited September 24, 2013 by digone52

[garethEds]

We had this issue but in the end I set then allow .exe from their MyDocuments\Visual Studio 2010\Projects directory - it's only available in my room.

 

I"m not a fan of lock and block. Don't agree with it. I understand why - but don't like it.

 

Gareth

[Ephelyon]

If virtualisation is the answer the school will use, it could be a good idea to look at automating snapshots and reversion every day/week, sort of like a poor-man's VDI. Over here we're very keen to support an exceptional group of pupils in learning about Python programming and, going forward, console access to a Ubuntu Server instance. I'm going to make it happen but I'm also going to be very conscious of all the security implications and I'll definitely be making sure that I can script/automate periodic snapshot restores from time to time.

 

Gareth, depending on the system setup we have to consider certain realities and at the end of the day we don't have to like it. The system exists to ensure that the school does; at the end of the day T&L is only one process among many from an org. man. standpoint. We know that schools exist to educate children but we can't afford to get ahead of ourselves in that respect when we consider the potential consequences of security breaches. I'm always quite explicit about that because in principle a security breach means nothing in itself (barring a lot of work for IT staff); what's important is the consequences of it. I do support the principle of a learning-focused organisation but I'm not going to pretend that it's okay to risk disclosures of sensitive personal data on staff, pupils or their families just so a few children can learn a few things that they could easily learn at a later stage in college anyway.

[TheScarfedOne]

I forgot to add, that the VMs are "read only" - they are essentially Live images, which exist on all machines - so once closed - any "fiddling" is lost. It means a completely flexible environment...they key was explaining the importance of saving to their home area!!!

 

I likewise understand the concerns...but we have to work a solution that keeps everyone happy. Part of the solution should include educating the students why it is set up in this way.

[Ephelyon]

A good point - if pupils question why it works that way we would be in a good position to tell them, and from experience too.

 

That solution almost makes me wonder if a customised version of XP Mode on Windows 7 could be an option, deployed only on the relevant workstations.

[unexus]

I've also been looking for ways to manage this. We have some students running Small Basic which seems to compile an exe in to the users home directory and then attempts to run it. I considered going down a VM route but have also been looking at Sandbox applications like Sandboxie. Has anyone taken this approach?

[garethEds]

Gareth, depending on the system setup we have to consider certain realities and at the end of the day we don't have to like it. The system exists to ensure that the school does; at the end of the day T&L is only one process among many from an org. man. standpoint. We know that schools exist to educate children but we can't afford to get ahead of ourselves in that respect when we consider the potential consequences of security breaches. I'm always quite explicit about that because in principle a security breach means nothing in itself (barring a lot of work for IT staff); what's important is the consequences of it. I do support the principle of a learning-focused organisation but I'm not going to pretend that it's okay to risk disclosures of sensitive personal data on staff, pupils or their families just so a few children can learn a few things that they could easily learn at a later stage in college anyway.

 

I agree totally but we also need to be aware that if a system is setup properly then there is not a lot the kids can do. We're not exactly running MI6 or storing military secrets.

 

Maybe it will shoot me in the arse but as it's only in my room which I monitor then it's not an issue for me.

 

I understand how bad a security breach can be. If pupils can access sensitive, personal data on staff just by opening .exe from a Virtual Studio project directory then is that stuff really safe?

 

Educate me. I'm not too arrogant that I will not listen to how we could be exposed. I am just a teacher after all ;-)

 

Gareth

[Ephelyon]

I imagine this will become another of my hallmark screen-filler posts and most will TL;DR.

 

Before I joined the big wide world of the grown-ups and began to use my skills for good, I had a "background" in this. I freely admit that because it was a long time ago and now provides me with insights I can use in a professional capacity, and I was only ever white hat. I'm going to give a number of relevant examples from intrusions I made, obviously without referencing exactly where.

 

In one environment (educational), a VNC server was installed on all workstations as part of a bigger package from a major vendor. Naturally this was inherently a problem as VNC stores server passwords and the manner in which they are obfuscated is insecure. It was only because I was able to issue commands like RegRead() that this mattered, however. Otherwise, and assuming no physical access to the box as ought to be the case, the password could have been stored in plain text for all the difference it would have made. It wasn't a problem until an attacker was provided with a way to read the data, which otherwise could not have occurred. The consequence was that I was able to view the screen of almost any workstation on campus, with all the obvious confidentiality implications that brings.

 

In another (Citrix sales demo environment), a domain admin account had what we might call a very guessable password. This was not the problem, however. The problem was that, owing to lax Group Policy restrictions, I was able to begin building up information on the target environment (server names, AD policies, virtual or not, etc) and eventually gained a list of usernames. Both the username and the password are ciphers to an outside attacker, which is why Windows doesn't tell you which you got wrong if you make a typo. Without knowing the username, it wouldn't have mattered at all that the choice of password was poor. The one problem wasn't relevant until the other existed. Because I was able to gain access to information that I shouldn't, lax security further down the line became relevant, and only then. The top and bottom of it is to never assume that you or a colleague have not slipped up somewhere else - the key is to make sure no potential attacker can find out about it! The amount of times I have been able to exploit the tiniest, most seemingly irrelevant detail to discover a more major problem down the line is unreal. This is no insult to anyone's skill or experience; it's the guideline I maintain for myself professionally as well, precisely because a significant proportion of intrusions I have carried out were possible SOLELY because someone in the equivalent of what is now my job made a silly mistake, was lax or lazy with security, didn't anticipate how information could be (mis)used or was generally a bit cr*p at their job. The implication here was that a critical sales tool could have been taken away from staff during presentations, causing no end of embarrassment and damage to the company if it happened regularly.

 

In another (Local Authority), the practice used to provide Internet access to many local schools through their broadband network was to give them all a username and password (which they had to type in EVERY time they opened a new browser session - unimaginable nowadays!), or in fact one set for admin, one for staff and one for pupils. These credentials were actually AD accounts in a central domain maintained by the LA, and were authenticated by a Windows-based proxy server which naturally had to have a domain computer account. On a lot of systems, an account will be created that has access to create, delete, disable or otherwise amend computer accounts, and solely to do specifically that. It will be created as a Domain User or Domain Guest, and the AD Delegation of Control Wizard will be used to give it the access rights required to the OU containing workstation accounts. It's typically used as the credentials for adding/removing workstations from the domain. That was the case on this system, except the security was misconfigured; those access rights had been granted at the root OU for all computer accounts, not just workstations but servers as well (Problem 1). Unfortunately, whether it was down to inappropriate routing or firewall port rules, it was possible to access shares on member servers of this central domain from individual schools (ports like 53 would have been needed, but why 139 as well?) - Problem 2. Anonymous enumeration of information such as user account names was also enabled on the domain controllers (Problem 3). One user account had the name "Public" - used for libraries and suchlike - and its password was easily guessable (Problem 4). This allowed me to connect to shares permitting read-only access to all Domain Users (not uncommon on larger systems). Lying around on one of those shares was what looked like an old, template SysPrep.inf file, containing the credentials of the domain-joining account (Problem 5), which were still valid (Problem 6). As a result, it was possible to disable the computer account used by the proxy server, such that no school Internet usernames/passwords could be authenticated, effectively taking down Internet access for the bulk of local schools. Despite being white hat I must admit I PoC'd this for two minutes, then reported the problem anonymously. But I've skipped ahead a little here because between Problem 2 and Problem 3 lies the Real Problem: I was able to run GFI LANGuard against the domain controllers. If that Real Problem of being able to run unapproved software (or, if you know what to look for, writing a simple programme that checks for these specific things) had not existed, then none of the rest would've mattered because I wouldn't have been able to glean the information in the first place. The problem with allowing both programming environments (that can read Registry keys, check for open ports, open a WMI connection to access data etc) and the execution of unapproved (compiled) software is that you enable problems that previously didn't matter, to now matter. You take all the Group Policy restrictions and etc that were specifically created to prevent this and effectively throw them out the window.

 

Consider one potential impact of illicit access to data here. Little Freddy dislikes Little Johnny and wants to beat him up but is wary of trying it in school. It's a big city and Freddy doesn't know Johnny's address. If he or a friend compromises the system and accesses this information, Johnny might find himself in hospital. If that event is ever causally linked back to the school, the people responsible will lose their careers and either way we are talking about an assault on a child. The reason I mention this is that during my own little phase, I had contact with others doing similar things. Not all were as white hat as I was; one of them was in the habit of actively selling the information they acquired (they had a few "personal issues") to whomever would pay enough for it; sometimes they wanted it for trivial reasons (egging staff's houses for example), other times for more sinister ones.

 

To come to the point, you're right to question whether that sensitive, personal data on minors and their families is really safe. Never assume it is. I can well imagine that the administrators of the systems I was able to compromise thought much the same thing. Having personally been that one factor that was missed, or not thought sufficiently important, a good few times, and knowing that children can be trained "groomed" by older hacker communities (as I was), the argument that school security breaches are either pretty much a myth or that their importance is overstated will never, ever wash either with me or with anyone else who has seen it, been it and done it.

[garethEds]

That is a brilliant answer and thank you for putting it out there for me to read. A lot to take in - I appreciate the time you have taken.

 

Regards

 

Gareth

[zag]

Block exe's using FRSM and let students use read only virtual machines

[NikChillin]

We use VMWare pro which has password protection to stop access to the network config area. Everything they do can be copied and pasted to their user area.

[RobFuller]

Virtual machines is how Ive managed this one. For us, we have built a Linux VM based on SLAX, which has loads of great programming utilities in it. In our case it was Python and Scratch among others. I read you need VB, but Im sure there must be some utils for it - or use an XP VM. Weve used VirtualBox, which has no network connection, but uses and allows access to the mapped U:\ (Home Drive) of the logged on user. Hey presto - file access and storage. They can write and run the code in the VM, save to their area, but not run the code from the normal network. I hope this makes sense.

 

How do you restrict the students from editing the VM configuration in VitualBox and reconnecting to the network or changing disk type?

[synaesthesia]

Search for virtualbox on these forums and you can see you can restrict everything and anything you like, from menus to configurations. Set up right, they wont even see VirtualBox other than the window with the OS on it.

[RobFuller]

Search for virtualbox on these forums and you can see you can restrict everything and anything you like, from menus to configurations. Set up right, they wont even see VirtualBox other than the window with the OS on it.

 

Section 9.20 in the manual looks like it will help! Thanks!

[Ephelyon]

As a talking point, how are people going about using virtualisation as a solution here? Are you hosting the VMs on a server or on each individual workstation? Is there an impact on the spec - and price - of said workstations if so (e.g. more RAM)?

[synaesthesia]

We have ours installed on each workstation. There's little to no impact - it's only installed in one ICT suite (likely to expand) but as the suites are built to a certain spec there isn't an issue - the spec includes virtualisation support at hardware level and 4GB ram. The VM's are told to use a single core and 1GB ram so even if we ran these on 2GB machines they're fine.

We help that by keeping the images uses for the VM's very light with NLite type utilities to strip out the nonsense, and only the relevant software installed (the IDE(s), Notepad++ etc ).

[Ephelyon]

Right, so as I suspected this is a solution that works but only if it's been actively worked into the spec based on a planned approach to the problem. Schools that just want to start having pupils creating and running problems willy-nilly without changing/spending anything would need to re-evaluate.

 

It does sound like the best way of doing it though. Can I ask how you're going about presenting this to the pupils? Is there a way of having seamless integration of virtual apps with the bare metal OS, à la XP Mode?

[synaesthesia]

We didn't spec anything up for it - sensible speccing for any workload just happens to also take care of this. We're not talking massive power or even big storage; 120GB SSD's, 4GB Ram and core i3's is plenty but they run just as happily on older dual core Pentiums.

 

There's no real integration; we use virtualbox's native ability to "map" a local drive (in this case the N:\ drive, the user's Home folder) into the VM. There's nothing else there, no network, no internet etc which means there's no security issues from users having full admin rights on the VM. Plus as they have immutable drives, once they're restarted, any changes are lost.

[Ephelyon]

We're not using SSDs as standard so that might have something to do with it Many schools are still standardising on 2GB RAM. We're trying to move forward with 4GB now.

 

There is some work going on from a security standpoint as to whether it's possible to "break out" of the virtual sandbox and execute instructions directly on the host. As it stands, there are 17 CPU instructions on the x86 architecture that can't be virtualised. It does seem the risk of this is pretty minimal for now though.

 

I for one would be interested to hear more. How have you deployed this? Is it part of a standard image?

[synaesthesia]

It's manually copied out at the moment as it's limited to 30 computers. If we need to do more (therefore making the likelihood of rebuilds higher) then it'll just get scripted to copy over via SCCM.

 

I hasten to add that initial testing on this was on a 2GB Pentium Dual Core (Conroe) machine with a HDD. Thinking about it, I believe the machines we're running them on are HDD. (all new stuff is SSD specified). It runs just as well, the W7 host is happy on 1GB and the guest is allocate 1GB too. Obviously there's overheads involved but as neither hits "the wall" there's no problem.

 

It's highly unlikely anyone will be using any of the host&guest instruction methods to "break out" of the VM and pose a security threat. If your network setup is solid anyway, that should never be an issue. My best piece of advice currently is not to over-complicate or get overly worried about minor things as it stands

 

One of our test boxes running ESXi is an old Xeon based HP ML110 - it has absolutely no more power than the old dual core Pentiums, yet it runs 4 VM's perfectly.

Edited September 29, 2013 by synaesthesia

[Ephelyon]

Indeed, there shouldn't be any problems there for the time being and that does sound like the best setup. What's the guest OS?

 

"If your network setup is solid anyway, that should never be an issue. My best piece of advice currently is not to over-complicate or get overly worried about minor things as it stands."

 

I think I made reference to that earlier.

[synaesthesia]

Absolutely. Guest OS is 7 also. Looked at using XP as it'd be a smaller image, and although it would naturally do the job as intended I felt it was no in the best interests of our students to give them an already long out of date system to play with - it should be current and applicable; for that very same reason it's 64bit too. I wouldn't have wanted to be forced to code everything with the date format DD/MM/YY when I did A-Level computing in the 90's, so the same applies now - I wouldn't expect anyone to be programming with a 32 bit base.

[Ephelyon]

Maybe there could be a way to cram it down into Starter Edition or something to save on space, but other than that it sounds fine.