One of the new features in the latest release of Phosphorus Five I am particularly proud of, is a much more mature access control implementation for users and roles. By default, any “root” account has access to *everything* and any non-root account has access to *nothing*. All accounts can however read from any files and folders in the system, since this is necessary to execute Hyperlambda – But writing to files is only (by default) allowed by root accounts. In addition, any non-root account, is by default only allowed to run the “desktop” module. This implies that if you create a non-root user, this user can’t do anything really, unless you explicitly open up for the role that the user belongs to to do something.
In addition, especially protected files, such as the “auth.hl” file (which contains users and their settings), in addition to the web.config, are impossible for any non-root account to read from (and of course write to).
The easiest way to control access to the system, is to use the Peeples module. This module allows you to create new users, associate a role with these users, and edit existing user. However, and more important for this article; It also gives you complete control over access to the entire system as you see fit. Notice, the Peeples module is most easily installed through the “Bazar”, by a root account, and only root accounts can create new users and assign access rights to roles, etc.
If I have a role called for instance “developer”, users belonging to this role does not have write access to anything. In addition your “developers” can not read from neither the web.config file, nor the auth.hl file. Neither can they open any modules, or run any “programs” in your system. If you want this role to have access to for instance Hyper IDE, you can assign an authorisation object for that role to “run” Hyper IDE. Below is an example of how you can accomplish this. Hint; Click the “+” button in Peeples at the bottom of your screen to open up this wizard window.
As I click the “Add” button above, I will have allowed my “developer” user to access Hyper IDE. This will create an “access object” looking like the following.
The thing to notice above, is first of all how the role becomes the root node’s name above. For our above example, this is the part that says “developer”. The GUID in the above screenshot, is just an automatically generated ID, which is necessary to be able to later delete a specific access object. Below our “developer” node though, we have a [p5.module.allow] node. This happens to be a specific type of access object, which the URL resolver will use, during loading of our apps and modules. You can see the code for it here if you wish. The [p5.auth.has-access-to-path] event is an integral part to the access control logic, and is implemented in the project “extras/p5.auth”.
The above access control object, will have granted access for our “developer” role, to execute the module in our “/modules/hyper-ide/” folder. Notice, you can also edit your access control objects by hand, since it’s simply a CodeMirror editor, and the access control objects are declared as Hyperlambda. If you do, remember to click the “Save” button afterwards, to have your new access control objects take effect.
Access to the file system
The above access control object will only give your “developer” users execution access to the Hyper IDE module. If you want to, you can also give it access to write to specific files and folders, by using similar logic. This part doesn’t have a GUI, but adding it by hand, by creating an access control object yourself, is quite easily accomplished. You could for instance write something like the following into the access control editor. Notice, you don’t need to give your access control object an ID, since one will be automatically assigned, if you choose to omit it.
The above access control object, would give any “developer” user access to write to any files beneath the folder “/modules/sephia-five/”, allowing him or her to effectively work on Sephia Five. The access control objects are “cascading” in nature, implying that your “developer” users, would also have access to write to for instance the “/modules/sephia-five/foo/bar/” folder for our above example. If you wish to explicitly deny access to some folder beneath your “/modules/sephia-five/” folder, yet still have the developer role being able to write to the Sephia Five folder in general, you could accomplish something like that by combining the above “allow” with the following “deny”.
Notice how we use the “deny” verb, instead of the “allow” verb. You can also allow and deny read access, by exchanging the above “write” verb to “read”. And finally, you can grant access to all roles, by exchanging the role name from “developer” to an asterix “*”. If you have some module, called for instance “sulphur-five”, which is an actual module in Phosphorus Five, you could grant access to all roles, including the “guest” account, with the following code.
This would of course give access to everyone to your Sulphur Five module, including any random visitor, belonging to the impersonated “guest” account too. If you only want logged in users to be able to access Sulphur Five, you could combine the above with an additional “deny” object, such as the following illustrates.
Since your “deny” have precedence, this would allow all non-guest users (users with a username and a password) to access your Sulphur Five module. While a guest account would have no access to it. Combining multiple access control objects like the above illustrates, basically give you 100% perfect control over who gets to access both your modules, and your file system.
Extendible access control
The access control logic is actually extendible. This allows you to create your own types of access control objects, and verify access in your own code. The [p5.system.platform.execute-file] event for instance, which will execute some shell script, will check for the existence of access to execute the file you try to execute. If you want users to for instance be able to execute anything within their private “temp” folders as shell scripts, you could use something such as the following.
The above access control object would allow “developer” accounts to execute any shell scripts that exists in their “/temp/” folders. The above example is actually quite relevant too in fact, since Hyper IDE will use the “temp” folder as a cache, while creating scripts it executes, to do stuff such as Git checkins, compilations, etc. Yet again, notice the “allow” verb in the above code.
All in all, I am very proud of how I have implemented access control in Phosphorus Five, which adds more security, to an already very secure system, which has features such as salted hashed passwords, stored such that only “root” account have access to it, etc, etc, etc. If you want to play around with Phosphorus Five or Hyper IDE, the easiest way to accomplish that, is to download the lates release of Phosphorus Five, since it contains also Hyper IDE in fact. My next major feature in regards to security, will be to implement brute force password cracking, where the idea for how to do this, actually came from Reddit.com.
Brute force password attack prevention (TODO)
Basically, my idea for how to implement this, is to not allow the same username to try more than one login attempt every “n seconds”. Since a brute force password crack, implies trying millions of different passwords, over some time period – Denying the same username to attempt to login, more than once every 10/20 seconds for instance, would increase the timespan necessary to successfully brute force attack a server, to such an extent, that it would be considered impractical.
Since this is to be implemented on usernames, and not on IP addresses or something similar – This implies that it wouldn’t even matter if a hacker had access to millions of different servers to attempt to crack your system. Sure, he could DOS your system, but he won’t be able to guess your password, using for instance a password dictionary or something similar.
Security in your underlaying operating system
I want to emphasise that these security measures comes in *addition* to the security that is in your underlaying operating system, such as for instance Linux/Apache – And that you can also use the underlaying operating system’s security features. An example would be to for instance during installation, allow the Apache process write access to the entire “html” folder, for then to install all modules you want to install. After this, you could explicitly deny write access to anything except the “/common/” and the “/users/” folders, editing your “apache2.config” file, or changing ownership of these folders using for instance “chown” in Linux.
This would make sure that even if there was a security flaw in Phosphorus Five, it would still be impossible to tamper with anything but the users’ files. All in all, security is like a condom; It’s better with 5 than only 1, and you should use as much of it as you can. Depending upon your needs though, the above might be impractical, especially if you want to setup a “developer server” using Hyper IDE. However, you could also add additional security by explicitly denying access to special modules, while granting access as a whole to the “/modules/” folder. In addition you can also create a special MySQL user, which doesn’t for instance have access to drop tables, create databases, etc, etc, etc – And only use this user to allow Phosphorus Five access to your MySQL instance (after having installed all apps you need, since this will need “create database” access to your MySQL server). In addition, if you’re extremely paranoid, there’s nothing preventing you from installing Phosphorus Five on your company’s intranet, having only access to it through e.g. a VPN client, etc, etc, etc …
Even though I have done my best to implement strong security in Phosphorus Five, you should still use the security features of your underlaying operating system. And in fact, the installation script for Phosphorus Five, which you can find here (“install.sh”) – will add tons of additional security to your underlaying Apache/Linux system, such as installing the “uncomplicated fire wall” (ufw), and shut down everything except port 80, 443 and 22 (SSH), in addition to adding lot of additional security features, such as denying Apache to serve files in your “/users/x/document/private/” folder, etc, etc, etc. In general, I’d like to echo the words of one of the father’s of Intel, the company …
Only the paranoid survives …