DLPX-86537 CIS: sudoers configuration

[dbshah12]

Problems

• This setting specifies the presence of 'use_pty' setting in /etc/sudoers and /etc/sudoers.d/ file. If set, sudo will run the command in a pseudo-pty. Attackers can run a malicious program using sudo which would fork a background process that remains even when the main program has finished executing. This setting should be configured according to the needs of the business.

• This setting specifies the presence of sudo log file on the system. A sudo log file simplifies auditing of sudo commands. Sudo provides users with temporarily elevated privileges to perform operations. And if it is enabled, creating an audit log of exactly what was run (and who ran it) is essential to reporting. This setting should be configured according to the needs of the business.

Solutions

• Edit /etc/sudoers.d/delphix and add below 2 lines in it to get logs of sudo commands:

Defaults use_pty
Defaults logfile=/var/log/sudo.log

• Add new /etc/logrotate.d/sudo-log for log rotation.

Testing

• Ab-pre-push: https://selfservice-jenkins.eng-tools-prd.aws.delphixcloud.com/job/appliance-build-orchestrator-pre-push/9531/ - Passed

Manual

• Checked the below details on the New machine with this change and upgraded DE:
  • These logs are not available on normal machines.

[sebroy]

We should not be making these changes using ansible. The idea of the "*.d" directories is that they can contain configuration fragments as files. You can simply include the files you want in the delphix-platform repo. For example, see how we already provide such a configuration fragment in the repo already in a file called delphix. We can do the same for logrotate configuration fragments.

[dbshah12]

We should not be making these changes using ansible. The idea of the "*.d" directories is that they can contain configuration fragments as files. You can simply include the files you want in the delphix-platform repo. For example, see how we already provide such a configuration fragment in the repo already in a file called delphix. We can do the same for logrotate configuration fragments.

Ohh yeah, I wasn't aware of it, I used delphix file to set below 2

Defaults use_pty
Defaults logfile='/var/log/sudo.log'

And also added a log rotator, @sebroy thanks for suggesting, can you please re-review? I will do testing again once, the pre-push completes.

[dbshah12]

We should not be making these changes using ansible. The idea of the "*.d" directories is that they can contain configuration fragments as files. You can simply include the files you want in the delphix-platform repo. For example, see how we already provide such a configuration fragment in the repo already in a file called delphix. We can do the same for logrotate configuration fragments.

Ohh yeah, I wasn't aware of it, I used delphix file to set below 2

Defaults use_pty
Defaults logfile='/var/log/sudo.log'

And also added a log rotator, @sebroy thanks for suggesting, can you please re-review? I will do testing again once, the pre-push completes.

@sebroy Completed the normal and upgrade testing, things are working as expected, can you please re-review?

[sebroy]

one last nit: we should be consistent with copyright blocks. In this case, one file has a copyright block, and the other does not. Either they should both have one, or neither should have one. IMO configuration files are not copyrightable code, and should not have a copyright block. As such, I suggest removing the copyright block from the sudoers.d file to make things consistent.

[dbshah12]

one last nit: we should be consistent with copyright blocks. In this case, one file has a copyright block, and the other does not. Either they should both have one, or neither should have one. IMO configuration files are not copyrightable code, and should not have a copyright block. As such, I suggest removing the copyright block from the sudoers.d file to make things consistent.

Yes, that's a good idea. However, I was thinking about something else:

I searched for the files with # Licensed under the Apache License, and all of them include a copyright notice. Should we consider adding this instead of removing it?

[nealquigley]

LGTM. I don't have strong feelings nor expertise in copyrights but per your comment, it seems like adding the same sort of block to the new file would be more consistent with the rest of the codebase than removing it from the preexisting file.

[dbshah12]

LGTM. I don't have strong feelings nor expertise in copyrights but per your comment, it seems like adding the same sort of block to the new file would be more consistent with the rest of the codebase than removing it from the preexisting file.

• Yeah, I agree with you on consistency but as @sebroy suggested configuration files are not copyrightable code so I removed it.