Resecure setup.gs and create tools required by the new security guidelines
Files affected
Which file(s) is(are) affected
setup.gs
New tools in order to create and rename a user
A fake ssh command which make sure a bouncing point can't be used against it's own lan
A fake sudo command which makes sure only root can sudo into a non-root user
And an admin tool to obtain a guest shell on non-ssh machines
Steps to reproduce
The exploit system was not taken into account during the design phase of setup.gs (see comments of issue #9 (closed) )
We need a tool to create a user without some of the user folder
We need to be able to rename a user to avoid opening some root exploit by mistake
Admins need a way to escalate up to root when ssh is not available
Expected behaviour
Assuming "secure" libraries are used, the default installation from setup.gs should be secure enough to avoid service disruption
With additional tools, we should be able to handle users better :
a) Create a user without the Config and .Trash folders
b) Create a user without its user folder
c) Rename a user (in order to not have a opportunity to run a root exploit)
Actual behaviour
setup.gs is able to create some users with read-write rights
However, said permissions are enough to scp exploits able to take control of the root user
Creating a user as A and B is possible with setup.gs, but it's a huge script meant to be run only once
However, renaming a user isn't possible in setup.gs at all, and the actual creation is too precise for our needs (at best, it should only create temporary users to patch some exploits)
Possible fixes
Fixing the vulnerability requires rethinking the design and (the way we use servers), by following the new security guidelines
Once said additional tools are added, user creation can be removed from setup.gs, which could be focused on the creation of a set amount of "placeholder" accounts to avoid root exploits