Harden security... 🔏

SuiteCRM Forum - English Language
1

is there anything that would compromise the functionality of SuiteCRM by setting folder and file permsions to:

  • Folders - From 755 to 750?

  • Files - From 644 to 640?
    I thought it would be good to strengthen/harden the permissions at bit, just in case…
    But before I do it I want to ask you guys if I should do this or not.

Please comment and tell me if this is possible…

Thanks in advance
Kind regards
PowerQuest

2

I agree with using a 0 for World permissions. But you need to keep the distinction from the recommended installation procedure, about some directories requiring write access, while others don’t need it.

Anyway, I don’t like our current permissions instructions. We should really make better ones, remove all “world” permissions, suggest a nice scheme where access happens from the Group bits, not the Owner bits. A few code tweaks would also be very beneficial in the area of permissions.

This is my favored set up these days:

  sudo chown -R pgr:www-data .
  sudo chmod -R 750 .
  sudo chmod -R 770 cache custom modules themes data upload
  sudo chmod 770 config_override.php 2>/dev/null

pgr is my individual user. I add it to the www-data group. This way I can edit files without breaking ownerships, and this way the web server actually uses that second digit (which varies between 5 and 7 for selected directories) instead of being owner and always using the first digit, which is always 7 - that defeats the purpose of trying to give write permissions only where strictly necessary.

Other users get nothing, not even read access. Read access to your config files is a huge security risk, there are DB admin passwords in clear text in there. We have some .htaccess protection for that, when attackers need to go through the Web server, but not much security from threats inside the same server (different users).

3

I always set the config.php, and some internal server files like phi.ini, user.ini, etc to 400 and .htaccess etc to 404 after I’ve upgraded. So I change that back after that from 644.

So 770 on folders (cache custom modules themes data upload), and 750 on files then for those directories that requires write access?

Can I set 640 for all other files and 750 on folders that do not require any write access/modification rights by the system/SuiteCRM?

Thanks in advance.
Kind regards
PowerQuest

4

It depends on the ownerships.

Will your web server be accessing the files as owner or as group? If as owner, you need to worry about the first digit in those numbers, and nothing else. If as group, you need to worry about the second digit.

5

Well it’s not shared a server per see, but one of our company servers so I might do as you suggest not give a rats ass about it. However we do have partitioned the server with C-panel (for easy management reasons) to run other services on it.

The only ones that have access to it is ourselves and our hosting company we have outsourced to.
I guess it is just me because I’m sort of a security freak and always look to improve if I can. It sucks to be hacked you know… :smirk:

But if I did go ahead and did this it would be no impact on the CRM with 640 right (On the non writeable folders)?

Thanks again. :+1:

Kind regards
PowerQuest

6

Can you answer this :point_up: ? It helps focus the discussion. We should be worrying about one digit at a time.

There’s a part of the answer that I don’t know exactly, I used to know this but I forgot, which is about whether the execute bit is needed for PHP files in order to get the web server to execute them. Maybe not, maybe it just needs to read them. But then maybe this is not the same for CLI versus web server, and SuiteCRM needs both.

7

I’m pretty sure Apache access the process as an owner.

Kind regards
PowerQuest

8

Not if it doesn’t own the files. :slight_smile:

Depends on what you used for chown command. My set up explained above does not give ownership to apache, it uses group logic instead. I find this facilitates a lot of things, namely whenever you log in as some user and edit files, and it breaks systems where apache is needing ownership. Then you would have to re-set the ownerships after each edit. Too much work.

1 Like