@@ -35,30 +35,24 @@ Fix : non-root users must *never* have execute rights to Browser.exe, *for all m
...
@@ -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
3b) Someone on the router is able to block the port
Fix : all those security measures must be applied on the router too
Fix : all those security measures must be applied on the router too
Copy from issue 9
I identified 4 types of (legitimate) users (besides root and guest)
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)
Note that the two last ones are *player* usecases and not GuildHack mission requirements
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?)
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
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
* "ssh" (Hosting Services mission) : users able to bounce through ssh
Permissions : "ssh" command. only that.
Permissions : "ssh" command. only that. (with custom no-lan filter!)
* "ftp" (Hosting Services mission) : users able to access the /Public/Downloads/ folder
* "ftp" (Hosting Services mission) : users able to get the files into the /Public/Downloads/ folder
Permissions : no commands (FtpShell). /Public/ as read, /Public/Downloads/ as read-write.
Permissions : no commands (FtpShell). /Public/ and /Public/Downloads/ as read
* "home" : users connected through ssh or ftp to download or edit files (BTCshop)
* "members" : users with a private space (guild members)
Permissions : /home/ ONLY. Users of this group should be assigned *another group* per usecase.
*This usecase, sadly, is nearly impossible to provide safely*
* "home+btc" : to allow external download with the player-made BTC client
A user shell exploit would easily lead to local escalation, then into compromission of the whole LAN!
*Exact permissions to be determined, I'm assuming the /home/USER folder*
* "btc" : to allow external download with the player-made BTC client
* "home+members" : users with a private space (guild members)
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*
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"
For completeness, here's the two special users who doesn't fit into the design :
If he should be able to access the ftp folder directly, addgroup "ftp"
* "root" : As no group requires sudo, the ssh access need to be done from the previous server
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
Data from other services (chat, web, ...) fall under ownership of root as no legitimate user need to access those files directly
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)
* "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
It's possible that GreyOS doesn't allow to refuse access to the /home/guest/ folder as well
