@@ -35,30 +35,24 @@ Fix : non-root users must *never* have execute rights to Browser.exe, *for all m
3b) Someone on the router is able to block the port
Fix : all those security measures must be applied on the router too
Copy from issue 9
THIS MODEL IS NOT SECURE TO THE WAY USERS CAN USE ESCALATION SCRIPTS DON'T USE THIS TEXT AS-IS!
For my understanding, I identified 4 types of (legitimate) users (besides root and guest)
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
All users should be able to access '/' in order to navigate easily (to check with an expert?)
Let's be nice and give "clear" so that everybody can reset their screens in ssh :P
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
* "ssh" (Hosting Services mission) : users able to bounce through ssh
Permissions : "ssh" command. only that.
* "ftp" (Hosting Services mission) : users able to access the /Public/Downloads/ folder
Permissions : no commands (FtpShell). /Public/ as read, /Public/Downloads/ as read-write.
* "home" : users connected through ssh or ftp to download or edit files (BTCshop)
Permissions : /home/ ONLY. Users of this group should be assigned *another group* per usecase.
* "home+btc" : to allow external download with the player-made BTC client
*Exact permissions to be determined, I'm assuming the /home/USER folder*
* "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"
For completeness, here's the two sepcial users who doesn't fit into the design :
* "root" : As no group as sudo, the ssh access need to be done from the previous server
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)
*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!
* "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*
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
