Implications of access by the user www-data to all friendica folders
Hi there,
the friendica helpers page describes the installation process of friendica as follows:
/help/Install: wrote:
The Linux commands to clone the repository into a directory "mywebsite" would begit clone https://github.com/friendica/friendica.git -b stable mywebsite cd mywebsitebin/composer.phar install --no-devMake sure the folder view/smarty3 exists and is writable by the webserver user, in this case www-data
mkdir -p view/smarty3 chown www-data:www-data view/smarty3 chmod 775 view/smarty3Get the addons by going into your website folder.
cd mywebsite
Clone the addon repository (separately):
git clone https://github.com/friendica/friendica-addons.git -b stable addon
askubuntu.com: wrote:
What is the www-data user?
askubuntu.com/questions/873839…
The web server has to be run under a specific user. That user must exist.If it were run under root, then all the files would have to be accessible by root and the user would need to be root to access the files. With root being the owner, a compromised web server would have access to your entire system. By specifying a specific ID a compromised web server would only have full access to its files and not the entire server.
I guess this observation goes both ways, a compromised friendica instalation get's access to all the friendica folders if I choose to first create/activate the www-data user, than create the friendica installation folder structure, than git clone friendica, than create the smarty3 folder and ultimately do the git clone of the addon folder as described here:
tupambae.org/display/0ac89072-…
The order in which the creation of www-data related folders in the above case is described makes all folders and files in the friendica directory belong to www-data.
In the friendica help description first comes the git-clone, than the the smarty3 folder part than the addon git-clone. Actually I guess that last part would make the addon folder belong to www-data too if I run one command after another. Is that intended?
I wonder if this could have some kind of security implications.
I guess www-data is somehow the friendica site and has permissions to do "what ever it wants" (-> "writable by the webserver user") with all the folders in the friendica directories if it's the owner of them.
Roland Häder likes this.
Hypolite Petovan
in reply to utopiArte • • •@utopiArte For a Friendica node to work properly, the web server user (here
www-data) needs to have read access to the whole Friendica folder structure and write access to a few important places, including the smarty3 cache folder. The simplest way to achieve this is to grant ownership to the whole Friendica file tree towww-data.The security implication is that if someone ever gains unauthorized access to
www-data, they can indeed do "whatever they want" with your Friendica install, including deleting files, adding malware to Friendica pages, access the whole Friendica database including the user list, the private post and messages.And if you host multiple websites on the same server, they can also access and tamper with those if their file trees are owned by the same user.
It's a big "if" though, as on Debian-based distribution like Ubuntu, the
www-datauser doesn't have shell access, meaning that you can't open a remote shell using this user. Any unauthorized access has to go through the actual hosted applications. For example WordPress is a popular unauthorized access vector for malicious actors because it's so popular and people don't always update their software timely.I don't think Friendica is very secure, but it is a low-profile target and we do act quickly when we receive security reports, even releasing hot fix versions when the scheduled release date is a little to far.
You can make your install marginally more secure by only giving access to the file tree through group permissions and only giving read/traverse rights by default, granting write rights only for the specific locations that need it. This way, in case of a malicious access, it will prevent attackers from inserting malicious code in your Friendica node pages, but that's about it.
like this
utopiArte and Shiri Bailem like this.
Friendica Support reshared this.
utopiArte
in reply to Hypolite Petovan • • •> granting write rights only for the specific locations that need it
What folders would that be?
What I have seen so far that would be:
/storage
/view/smarty3
and
/config
but only while installing local.config.php
Something I don't understand is why I do have a few folders in:
/view/smarty/compiled
that belong to the user root.
How is that possible?
How can friendica create folders as and/or for root?
What should I expect to happen if I just delete those folders, or even delete the complete /compiled folder. I guess friendica would start from there to create the folder compiled and subfolders as needed?
I ask because there are those subdirectories belonging strangely to root and one of my issues is that when I switch to the theme FRIO I have no access anymore to the settings of that respective profile, not even to change back to VIER. That renders that profile nearly useless and I'm trying to get around that problem.
Friendica Support reshared this.
Hypolite Petovan
in reply to utopiArte • • •@utopiArte That's a good list of exceptions.
Regarding the root-owned folders, it would prevent
www-datafrom reading the cached template files and subsequently display the pages that uses the specific templates in this folder.You should restore recursive
www-dataownership to this or these folders. Please let me know if you need an example of a command line to do so.utopiArte likes this.
Friendica Support reshared this.
utopiArte
in reply to Hypolite Petovan • • •I guess to just change all the folders/subfolders and files regardless of their ownership that would be:
rootname@VPShosting:/var/www/html/view/smarty3/#
chown -R www-data:www-data compiledHypolite Petovan likes this.
Friendica Support reshared this.
Hypolite Petovan
in reply to utopiArte • • •Friendica Support reshared this.
utopiArte
in reply to Hypolite Petovan • • •Just checked the settings page of one of the profiles in question and yes, that fixed it.
thx
👍
(again, how could this possibly happen, shouldn't we look for some bug somewhere or do we just assume some quantum entanglement?)
Friendica Support reshared this.
utopiArte
in reply to utopiArte • • •result:
What I don't get is where these ownership settings came from.
They were not even from a specific day or had anything specific in common:
tupambae.org/display/0ac89072-…
utopiArte
2023-11-26 22:07:25
Friendica Support reshared this.
Shiri Bailem
in reply to utopiArte • •@utopiArte @Hypolite Petovan this is most likely just some goof while doing something minor that you wouldn't have even connected to this at the time.
No amount of proficiency and watchfulness eliminates user error, it just becomes increasingly obscure.
Friendica Support reshared this.
utopiArte
in reply to Shiri Bailem • • •Even tho there have been some trouble while setting up this installation what calls my attention ist that those folders had kinda random different dates of creation:
Friendica Support reshared this.
Hypolite Petovan
in reply to utopiArte • • •Friendica Support reshared this.
utopiArte
in reply to Hypolite Petovan • • •Friendica Support reshared this.
Shiri Bailem
in reply to utopiArte • •Friendica Support reshared this.
utopiArte
in reply to Shiri Bailem • • •That's what astonishes me.
My access is only via console SSH to the VPS and that shouldn't create any kind of cross implications with the firefox webbrowser that accesses the friendica installation.
Also apparently the installation itself was created the 8th of November, the first folder apparently the 11th of November so there was no relation to that.
If friendica is able to create a folder and files as root that's kinda scary isn't it?
Friendica Support reshared this.
Shiri Bailem
in reply to utopiArte • •@utopiArte @Hypolite Petovan it's not able to, and if it was it would be considered a massive linux security bug rather than a friendica bug.
SSH and VPS mean nothing for this situation, you likely just ran something with sudo at some point.
Friendica Support reshared this.
utopiArte
in reply to Shiri Bailem • • •Friendica Support reshared this.
utopiArte
in reply to Hypolite Petovan • • •> That's a good list of exceptions.
In theory I could there for run the following commands to set all folders except /storage and /view/smarty3 to root:
set ownership of everything recursively to root:
rootname@VPShosting:/var/www/#
chown -R root:root htmlset ownership of storage and smarty3 recursively to www-data:
rootname@VPShosting:/var/www/html/#
chown -R www-data:www-data storagerootname@VPShosting:/var/www/html/view/#
chown -R www-data:www-data smarty3The change of ownership wouldn't affect the specific read/write permissions of files and folders and www-data would have only access to the folders needed.
right?
Friendica Support reshared this.
Hypolite Petovan
in reply to utopiArte • • •utopiArte likes this.
Friendica Support reshared this.
utopiArte
in reply to Hypolite Petovan • • •I ended up doing the following:
First I created a backup folder of the existing html folder and subdirectories:
root@VPShosting:/var/www#
cp -r html html_01.bakBy default that created a copy with all files and folders owned by root.
Than I changed the ownership of storage and smarty3 to www-data:
root@VPShosting:/var/www/html_01.bak#
chown -R www-data:www-data storageroot@VPShosting:/var/www/html_01.bak/view#
chown -R www-data:www-data smarty3Once everything looked "fine" I moved the existing html folder to a new name.
root@VPShosting:/var/www#
mv html html_www-data_oldBy moving [mv] instead of copying [cp] the ownership of files and folders aren't affected. Than I moved the copy with the new ownership settings into place:
root@VPShosting:/var/www#
mv html_01.bak htmlWell see how this setup behaves.
In any case I'll have the old version at hand to change to it if necessary.
Hypolite Petovan likes this.
Friendica Support reshared this.
Shiri Bailem
in reply to utopiArte • •@utopiArte security implications are minor, mostly because they can only edit the thing they've already hacked into.
But if that's a particular concern, you should be able to make the entire directory read-only as I don't believe friendica edits any of those files after initial setup (since all the edits are in database, or a separate storage folder if you're using the folder storage backend)
The writable in your quoted instructions is for the setup process while logged in under that user, so of course it'll need write to be able to download files and install them in the webserver directory. But there's no indication that it's needing write past that.
utopiArte likes this.
Friendica Support reshared this.