root access?

[jerch]

Just a minor heads-up:

Is giving root access to anyone a good idea? Note that this will attract evil kids misusing your service for all sort of shady things, up to a point, where your cloud provider has to tear down the service (Is it Microsoft/Azure? At least thats what I get from WHOIS). And if greater harm is done through your service, you can get into serious lawyer trouble (at least thats how it works here in Europe).

Idea: If your goal is to give random users the chance to get used to a POSIX like system, maybe start with normal user privileges and a good set of preinstalled apps. Try to avoid anything like compilers or even interpreters.
On a second level allow users to ask for root access, but then you'd have to ask for some identity and to make sure, they dont misuse your service. Thats very tough and involves serious metrics, def. not easy to get done right.

Other idea: Allow root access right from the beginning, but dont allow any internet access. This way ppl cannot use it to spread malicious things directly (they'd have to copy things over). Pll can still bug you with tons of computation time, thats always your risk on the cloud computing time balance.

[tsadarsh]

Hi @jerch. Thank you for sharing your insight. This really got me into thinking.

When I started out, I thought of the dangers in giving root access. I personally do not know much on hacking and any evil stuff that can be done using a terminal. But from your viewpoint it seems damage can be done. Let me take your word.

Yes, I am running a VM in Microsoft Azure. Each new ucli-terminal session binds to a new docker container in the VM. So the user does not have any access to the VM itself. If someone is able to use this service to do bad stuff, it can also be done in many other ways too, right? Like, anyone can download the Ubuntu Image and anyone can hide their IP using a VPN, Tor (or proxy servers).

I may be mistaken. I see the only advantage in using ucli to do bad stuff is their IP isn't directly exposed (or is it?). Linux distros nowadays can be run on any machine by just using a USB boot-loader. Don't they possess these same security risks?

[jerch]

Yes thats true, with properly set up VPN anyone can cloak its roots.

The problem here - the victims will contact the provider in question (MS), and they will refer to you as "service provider". This kinda puts you in a legal position with all consequences. Thats a risk you put on your side. Dont get me wrong, I like easy and convenient stuff (like your service is), sadly as soon as its open to the internet, the bad guys will show up. Btw I had to learn that the hard way once with a weak git password while learing git years ago. Took them 30min to undermine a server, grrr.

Whats the difference to your USB scenario?
You make it easy for those kids - you offer free computation time with full root + internet access, thus they dont need to care about getting their hands on someone else's computer. They simply spawn several instances and let the bad things happen. Furthermore the cloud infrastructure of Azure gives them another obfuscating indirection for free (containers come and go as needed on different data center machines, very hard to track down from outside). All they now need to be really safe - another VPN to access your service from.

Edit:
If you share the concerns I listed above - maybe try to ask http://polarhome.com/, how they secure their free accounts against malicious activity. They are offering free shell access accounts for quite some years and prolly have deep insights.

[tsadarsh]

This is very interesting. It amazes me the possibilities to misuse a tool.

Will a "policy" or some sort of "Terms and conditions" put up a notice and evade me from facing legal consequences? Of course this is a very selfish way of thinking.

I don't want to restrict users by not giving them internet access. If there is no root permission, one cannot install any package, which defeats the whole purpose of ucli. Maybe I can place an authentication system like "Google Sign-In" before entering a shell session and keep track of users using the service.

Edit:
I just saw your edit and I'm convinced that ucli can be put to bad use. This is so sad. Should I take down the service now?

Here I'm listing the advantages that a bad kid has in using this service:

1. Free computation time
2. Makes user anonymous
3. One user can spawn multiple instances

Proposed solution:

1. Placing an authentication system like "Google Sign-In" to remove anonymity.
2. Time bound session (like 30mins shell life) and per day time quota.
3. Every signed in user gets only one active shell. Only after destroying first instance can user create second one.

[jerch]

Yeah, your proposed steps sound really good 👍

There is one more thing - everything that creates costs will drive the bad guys away. Examples:

• a captcha creating real user time cost (but be warned - some captcha libs are machine predictable already, it will still keep most script kiddies away, as the way to overcome a captcha is coding extensive)
• throttling in CPU time - can keep guys away that want to do number crunching with your service (e.g. password cracking)
• throttling inet speed - can keep guys away, that want to spam or DDOS from your service
• higher functionality (like root/inet access) for real money - no mail spammer will ever bug you, if your service costs outweigh their profit

About the legal situation I cannot give any advise (I am not a lawyer). It is def. a good idea to get some sort of authentication through a 3rd party service like "Google Sign-In", so you can delegate partial responsibilities by some kind of legal terms, yeah.

Really would be a shame if you have to tear down your service because of the bad guys. Imho with some counter measures and some alert metrics (if one container creates very high inet loads - pull the plug, whatsoever) it will be very helpful service. 😸