@@ -37,6 +37,7 @@ Fix : all those security measures must be applied on the router too
I identified 4 types of (legitimate) users (besides root and guest)
Note that the two last ones are *player* usecases and not GuildHack mission requirements
+ one extra legitimate use if a future feature is added the way I think it'll be
All human users should be able to access '/' in order to navigate easily
Let's be nice and give "clear" so that everybody can reset their screens in ssh :P
...
...
@@ -44,18 +45,30 @@ Let's be nice and give "clear" so that everybody can reset their screens in ssh
Permissions : "ssh" command. only that. (with custom no-lan filter!)
* "ftp" (Hosting Services mission) : users able to get the files into the /Public/Downloads/ folder
Permissions : no commands (FtpShell). /Public/ and /Public/Downloads/ as read
* "members" : users with a private space (guild members)
* "home" : users connected through ssh or ftp to download files in /home/
Permissions : ONLY /home/ as read. Users of this group should always be assigned *another group* according to the usecase.
* "home+members" : users with a private space (guild members)
*This usecase, sadly, is nearly impossible to provide safely*
A user shell exploit would easily lead to local escalation, then into compromission of the whole LAN!
Design for this group can be found below.
* "btc" : to allow external download with the player-made BTC client
Read access is required for /server/, /server/shop/ and /server/info/ ... however, given the closed-source requirement AND the criticality of those files, it is advised to *run BTC as root*
* "gateway" (theorical) : assuming encrypted connexions becomes a thing, it'll be required to not leak the root password during the handshake process
Permissions: sudo ONLY
For completeness, here's the two special users who doesn't fit into the design :
* "root" : As no group requires sudo, the ssh access need to be done from the previous server
Data from other services (chat, web, ...) fall under ownership of root as no legitimate user need to access those files directly
* "guest" : Can't be deleted. No permissions (besides reading /, clearing his own terminal)
It's possible that GreyOS doesn't allow to refuse access to the /home/guest/ folder as well
* "root" : Data from other services (chat, web, ...) fall under ownership of root as no legitimate user need to access those files directly
* "guest" : Can't be deleted. No permissions (besides reading /, clearing his own terminal). Removal of the /home/guest folder as well.
About the "members" group (assuming it's for a machine sitting alone on it's own LAN!) :
* "home+members" : users with a private space (guild members)
Permissions : (/home/ as read), user folder as read-write, a lot of file commands
If a remote user is allowed to use the server as a proxy, addgroup "ssh"
If he should be able to access the ftp folder directly, addgroup "ftp"
*Reminder: due to how ser exploit works, those members are an open door towards script execution, then local escalation!*
Part 1: Basic permissions
...
...
@@ -64,14 +77,13 @@ Part 1: Basic permissions
* Give execution rights to everyone for "/bin/clear"
* Create the groups and add them to users accordingly
* Set group for /Public/ as "ftp" and give it group-level read
* Set group for /Public/Downloads/ as "ftp" and give it (recursive) group-level read-write
* Set group for /Public/Downloads/ as "ftp" and give it (recursive) group-level read
Part 2: Deleting unnecessary tools
* Delete the home folder of guest + "ssh"/"ftp"-only users
* It would be a good idea to delete/reset the /Config/ folder for all users, just in case (and the log file too)
* Nslookup, whois, Mail.exe aren't useful on a server, maaaybe on a dedicated proxy... delete it
* At the time of writing, there's no obvious benefit with not deleting CodeEditor.exe and build
* It would be a good idea to delete/reset the /Config/ and /.Trash/ folders for all users, just in case (and the log file too)
* Nslookup, whois, Mail.exe aren't useful on a server, maaaybe on a dedicated proxy... delete them to free drive space! Same with CodeEditor.exe and build
* Are members allowed the use this server as a *last-point* proxy to reach a ftp? If not, delete the ftp command
* If "destructive security" is desired, delete /etc/passwd and the services in /server/ (to prevent a shutdown)
