Securing-a-server/Identify-secure-libraries.md

@@ -35,10 +35,10 @@ After taking into consideration said requirements, here's the effect of exploits
 - A "user password reset" exploit add the "blue" modifier, as any service depending on a non-root account can be blocked by changing the password (as it's a modifier, the library will be either orange-blue or green-blue)  
 - If an admin can obtain an execution shell thanks to the library (preferably, a guest shell exploit), the library is at least "green". *By definition, ssh fits this requirement even without a shell exploit.*  
 
-Basically, it's impossible to work with red, and you need at least a green library on the server. If a library has the blue modifier, then all allowed services will need to run as root.  
+Basically, it's impossible to work with red, and you need at least one green library on the server. If a library has the blue modifier, then all allowed services will need to run as root.  
 
 In theory, there's even one even better level of library, represented by the color gold.  
-If all the service libraries are gold, then (assuming sudo -u is locked for guest) *the server will be secure even if the users have write access*.  
+If all the service libraries are gold, then (assuming sudo -u is locked for guest) *the server will be secure even if the users have write access* as long guest has no write permissions and can't access any directory the users can write.  
 In practice, it's only useful in order to create an ftp server where users have to ability to upload files.  
 
 Such libraries not only fit the requirements for "green without blue" level, but they also don't allow to obtain a user-level execution shell. *By definition, ssh never fits this requirement.*