DLPX-86533 CIS: default umask

[abhi2196]

Problem

(5.76) 4726 Current 'UMASK' setting for the '/etc/bashrc or /etc/bash.bashrc' file

The 'default UMASK permissions' determine what [default] privilege level will be set upon directories and files created by the user. The usual manufacturer default is '022.' If set at this value, when creating a new file, the resulting default permissions will be '644' (666 minus 022, i.e. -rw-r--r--). When creating a new directory, these default permissions will be 755 (drwxr-xr-x), which sets the access level to (rwx r-x r-x): for owner (rwx), group (read/execute), other (read/execute) access on file access. If users are not properly restricted, sensitive system or business information may be improperly disclosed. The most restrictive setting is 077 and your default file permissions would be 600 (-rw-------) and your default directory permissions would be 700 (drwx------), thus becoming (rwx --- ---): for owner (rwx), group (no access), other (no access). Also, as a malicious user could lay the groundwork for a privilege escalation attack by changing the UMASK value in this configuration file, access to this file and its UMASK setting should be restricted appropriately.

Remediation: # Edit file '/etc/bash.bashrc' to configure 'UMASK' setting according to the business needs and organization's security policies.

UMASK <number>

# Example UMASK 027

(5.77) 12884 Status of 'umask' setting in /etc/profile and /etc/profile.d/*.sh files

The default umask determines the permissions of files created by users. The user creating the file has the discretion of making their files and directories readable by others via the chmod command. Users who wish to allow their files and directories to be readable by others by default may choose a different default umask by inserting the umask command into the standard shell configuration files ( .profile , .bashrc , etc.) in their home directories. Setting a very secure default value for umask ensures that users make a conscious choice about their file permissions. A default umask setting of 077 causes files and directories created by users to not be readable by any other user on the system. A umask of 027 would make files and directories readable by users in the same Unix group, while a umask of 022 would make files readable by every user on the system. This setting should be configured according to the needs of the business.

Remediation:

Run the following command to verify the 'umask' setting in '/etc/profile and /etc/profile.d/*.sh' files. $sudo grep "umask" /etc/profile /etc/profile.d/*.sh
umask 027

Edit the 'etc/profile and /etc/profile.d/*.sh' file to configure 'umask' setting according to the business needs and organization's security policies.
umask <permissions>

# Example umask 022

Solution

• Added a file /etc/profile.d/set-umask-for-all-users.sh to set umask to 022 also added the same in /etc/bash.bashrc file as well.

Testing Done

• ab-pre-push: http://selfservice.jenkins.delphix.com/job/github/job/delphix/job/delphix-platform/job/appliance-build-orchestrator/job/pre-push/282/console Failed due to issue in yml syntax
• ab-pre-push: http://selfservice.jenkins.delphix.com/job/github/job/delphix/job/delphix-platform/job/appliance-build-orchestrator/job/pre-push/291/ Passed
• Commit 2, ab-pre-push: http://selfservice.jenkins.delphix.com/job/github/job/delphix/job/delphix-platform/job/appliance-build-orchestrator/job/pre-push/300/ Passed
• Created an engine and validated that umask value is getting updated for the users.
• Commit 3, ab-pre-push: http://selfservice.jenkins.delphix.com/job/github/job/delphix/job/delphix-platform/job/appliance-build-orchestrator/job/pre-push/303/ Passed

[sebroy]

Note to @dbj-delphix and @prakashsurya, this change has a chance of negatively impacting variants that aren't covered in ab-pre-push automated testing:

1. dcol
2. the build server

If you have recommendations on how to mitigate the risks here, please do suggest them. I don't see an immediate risk to dcol given that this would only impact new deployments, but the build server image is frequently re-built. That's the one I'm most concerned about.

[prakashsurya]

@sebroy if you're suggesting/asking if we could generate a buildserver with this change, and then rebuild all packages with that buildserver, I'm sure we can accomplish that.. Iet me see how we might do that..

[prakashsurya]

Iet me see how we might do that..

as-is, we'd have to build the variant via git-ab-pre-push -v internal-buildserver, and then use a modify devops-gate to test the builds on the resultant image.. I'll look into making changes to devops-gate, to allow the buildserver image to be passed into the jobs.. today, we don't support that, but no reason we couldn't, and enable us to more easily pre-push test the buildserver image and workload..

[prakashsurya]

I'll look into making changes to devops-gate, to allow the buildserver image to be passed into the jobs..

I've opened: https://github.com/delphix/devops-gate/pull/1524

[prakashsurya]

git-ab-pre-push -v internal-buildserver -p aws --no-tests is here

[prakashsurya]

Running the builds with this change here