Hello folks,
got question related with CCE-26966-2 (2.4.1.1.e Ensure That System Accounts Do Not Run a Shell Upon Login) - when thinking about implementing the remediation for this rule, noticed the following.
The purpose of remediation for this rule should be to disable shell for all non-root system accounts. When trying this on RHEL-6 noticed for 'postgres' user / postgresql-server RPM package the postgresql service would stop working:
* to be able to start postgresl, postgresql's database needs to be initialized first (service postgresql initdb).
* but when 'postgres' account is disabled (having /sbin/nologin in /etc/passwd) the following two (from what I tested) fails to succeed:
# service postgresql initdb # service postgresql stop (when already running)
# service postgresql start seems to work even when 'postgres' account is disabled on the system.
Besides that it's necessary to mention, that after starting postgresql daemon the administrator needs to create particular databases, user accounts etc.
These actions (createuser / createdb) seem to fail again when 'postgres' user is disabled.
Tested the similar scenario with 'mysql' user account package, and the actions (mysqld start, stop, db / user account, tables) creation seems to work even with 'mysql' user account's disabled.
Long story short - the question - based on the above should we whitelist [*] the 'postgres' account, when checking system compliance against the CCE-26966-2 rule?
Without whitelisting it looks applying the remediation for this rule will break system admin's capability to actually use the PostgreSQL service (initdb, stop etc. fail to work).
If not whitelisting the 'postgres' account, should we add a note into the guide, that applying remediation will make PostgreSQL service fail to work? (to prevent possible future customer's bug reports due this when remediated)
Since 'mysql' is working even with disabled shell access, should we check with PostgreSQL upstream if it would be possible modify the postmaster's behaviour it to be able to initdb / stop / etc. even with disabled shell access for 'postgres' user?
Comments appreciated.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] like allow the 'postgres' account to have shell defined under particular /etc/passwd row
If the account is locked, rather than disabled via shell, this problem vanishes.
Thanks, Leland -- Leland Steinke, Security+ DISA FSO Technical Support Contractor tapestry technologies, Inc 717-267-5797 (DSN 570) leland.j.steinke.ctr@mail.mil (gov't) lsteinke@tapestrytech.com (com'l)
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap- security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jan Lieskovsky Sent: Tuesday, December 10, 2013 5:14 AM To: scap-security-guide@lists.fedorahosted.org Subject: Whitelist 'postgres' user from OVAL check for CCE-26966-2 (2.4.1.1.e Ensure That System Accounts Do Not Run a Shell Upon Login)
Hello folks,
got question related with CCE-26966-2 (2.4.1.1.e Ensure That System Accounts Do Not Run a Shell Upon Login) - when thinking about implementing the remediation for this rule, noticed the following.
The purpose of remediation for this rule should be to disable shell for all non-root system accounts. When trying this on RHEL-6 noticed for 'postgres' user / postgresql-server RPM package the postgresql service would stop working:
to be able to start postgresl, postgresql's database needs to be initialized first (service postgresql initdb).
but when 'postgres' account is disabled (having /sbin/nologin in /etc/passwd) the following two (from what I tested) fails to succeed:
# service postgresql initdb # service postgresql stop (when already running)
# service postgresql start seems to work even when 'postgres' account is disabled on the system.
Besides that it's necessary to mention, that after starting postgresql daemon the administrator needs to create particular databases, user accounts etc.
These actions (createuser / createdb) seem to fail again when 'postgres' user is disabled.
Tested the similar scenario with 'mysql' user account package, and the actions (mysqld start, stop, db / user account, tables) creation seems to work even with 'mysql' user account's disabled.
Long story short - the question - based on the above should we whitelist [*] the 'postgres' account, when checking system compliance against the CCE-26966-2 rule?
Without whitelisting it looks applying the remediation for this rule will break system admin's capability to actually use the PostgreSQL service (initdb, stop etc. fail to work).
If not whitelisting the 'postgres' account, should we add a note into the guide, that applying remediation will make PostgreSQL service fail to work? (to prevent possible future customer's bug reports due this when remediated)
Since 'mysql' is working even with disabled shell access, should we check with PostgreSQL upstream if it would be possible modify the postmaster's behaviour it to be able to initdb / stop / etc. even with disabled shell access for 'postgres' user?
Comments appreciated.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] like allow the 'postgres' account to have shell defined under particular /etc/passwd row _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
This is good "institutional knowledge" usefully for someone troubleshooting a system. It would be nice to somehow capture this knowledge somewhere. Is the STIG Benchmark the right place for such information? Also can the fix disruption attribute be leveraged to indicate warnings about potential issues to a fix.
Below is the fix disruption attribute excerpt from the XCCDF specification. An estimate of the potential for disruption or operational degradation that the application of this fix will impose on the target. When specified, the attribute SHALL have one of the following values: - unknown (disruption not defined) (default) - low (little or no disruption expected) - medium (potential for minor or short-lived disruption) - high (potential for serious disruption)
Thanks.
Luis Nunez J83B - Industry Collaboration The MITRE Corporation www.mitre.org
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Steinke, Leland J Sr CTR DISA FSO (US) Sent: Tuesday, December 10, 2013 9:41 AM To: scap-security-guide@lists.fedorahosted.org Subject: RE: Whitelist 'postgres' user from OVAL check for CCE-26966-2 (2.4.1.1.e Ensure That System Accounts Do Not Run a Shell Upon Login)
If the account is locked, rather than disabled via shell, this problem vanishes.
Thanks, Leland -- Leland Steinke, Security+ DISA FSO Technical Support Contractor tapestry technologies, Inc 717-267-5797 (DSN 570) leland.j.steinke.ctr@mail.mil (gov't) lsteinke@tapestrytech.com (com'l)
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap- security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jan Lieskovsky Sent: Tuesday, December 10, 2013 5:14 AM To: scap-security-guide@lists.fedorahosted.org Subject: Whitelist 'postgres' user from OVAL check for CCE-26966-2 (2.4.1.1.e Ensure That System Accounts Do Not Run a Shell Upon Login)
Hello folks,
got question related with CCE-26966-2 (2.4.1.1.e Ensure That System Accounts Do Not Run a Shell Upon Login) - when thinking about implementing the remediation for this rule, noticed the following.
The purpose of remediation for this rule should be to disable shell for all non-root system accounts. When trying this on RHEL-6 noticed for 'postgres' user / postgresql-server RPM package the postgresql service would stop working:
to be able to start postgresl, postgresql's database needs to be initialized first (service postgresql initdb).
but when 'postgres' account is disabled (having /sbin/nologin in /etc/passwd) the following two (from what I tested) fails to succeed:
# service postgresql initdb # service postgresql stop (when already running)
# service postgresql start seems to work even when 'postgres' account is disabled on the system.
Besides that it's necessary to mention, that after starting postgresql daemon the administrator needs to create particular databases, user accounts etc.
These actions (createuser / createdb) seem to fail again when 'postgres' user is disabled.
Tested the similar scenario with 'mysql' user account package, and the actions (mysqld start, stop, db / user account, tables) creation seems to work even with 'mysql' user account's disabled.
Long story short - the question - based on the above should we whitelist [*] the 'postgres' account, when checking system compliance against the CCE-26966-2 rule?
Without whitelisting it looks applying the remediation for this rule will break system admin's capability to actually use the PostgreSQL service (initdb, stop etc. fail to work).
If not whitelisting the 'postgres' account, should we add a note into the guide, that applying remediation will make PostgreSQL service fail to work? (to prevent possible future customer's bug reports due this when remediated)
Since 'mysql' is working even with disabled shell access, should we check with PostgreSQL upstream if it would be possible modify the postmaster's behaviour it to be able to initdb / stop / etc. even with disabled shell access for 'postgres' user?
Comments appreciated.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] like allow the 'postgres' account to have shell defined under particular /etc/passwd row _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 12/10/13, 10:01 AM, Nunez, Luis K wrote:
This is good "institutional knowledge" usefully for someone troubleshooting a system. It would be nice to somehow capture this knowledge somewhere. Is the STIG Benchmark the right place for such information? Also can the fix disruption attribute be leveraged to indicate warnings about potential issues to a fix.
Below is the fix disruption attribute excerpt from the XCCDF specification. An estimate of the potential for disruption or operational degradation that the application of this fix will impose on the target. When specified, the attribute SHALL have one of the following values:
- unknown (disruption not defined) (default)
- low (little or no disruption expected)
- medium (potential for minor or short-lived disruption)
- high (potential for serious disruption)
Thanks.
Luis Nunez J83B - Industry Collaboration The MITRE Corporation www.mitre.org
This is reasonable. Opened an RFE to track this. Feel free to add yourself @ https://bugzilla.redhat.com/show_bug.cgi?id=1040111
I have experienced the same as Jan on my build that uses postgres.
Leland, you are saying I can just lock the account, and it will pass the check? If so I will give this a try here, as I didn't even think of trying that.
R/ Brian
On Tue, 10 Dec 2013 14:41:01 +0000, "Steinke, Leland J Sr CTR DISA FSO (US)" wrote:
If the account is locked, rather than disabled via shell, this problem vanishes.
Thanks, Leland -- Leland Steinke, Security+ DISA FSO Technical Support Contractor tapestry technologies, Inc 717-267-5797 (DSN 570) leland.j.steinke.ctr@mail.mil (gov't) lsteinke@tapestrytech.com (com'l)
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap- security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jan Lieskovsky Sent: Tuesday, December 10, 2013 5:14 AM To: scap-security-guide@lists.fedorahosted.org Subject: Whitelist 'postgres' user from OVAL check for CCE-26966-2 (2.4.1.1.e Ensure That System Accounts Do Not Run a Shell Upon Login)
Hello folks,
got question related with CCE-26966-2 (2.4.1.1.e Ensure That System Accounts Do Not Run a Shell Upon Login) - when thinking about implementing the remediation for this rule, noticed the following.
The purpose of remediation for this rule should be to disable shell for all non-root system accounts. When trying this on RHEL-6 noticed for 'postgres' user / postgresql-server RPM package the postgresql service would stop working:
to be able to start postgresl, postgresql's database needs to be initialized first (service postgresql initdb).
but when 'postgres' account is disabled (having /sbin/nologin in /etc/passwd) the following two (from what I tested) fails to succeed:
# service postgresql initdb # service postgresql stop (when already running)
# service postgresql start seems to work even when 'postgres' account is disabled on the system.
Besides that it's necessary to mention, that after starting postgresql daemon the administrator needs to create particular databases, user accounts etc.
These actions (createuser / createdb) seem to fail again when 'postgres' user is disabled.
Tested the similar scenario with 'mysql' user account package, and the actions (mysqld start, stop, db / user account, tables) creation seems to work even with 'mysql' user account's disabled.
Long story short - the question - based on the above should we whitelist [*] the 'postgres' account, when checking system compliance against the CCE-26966-2 rule?
Without whitelisting it looks applying the remediation for this rule will break system admin's capability to actually use the PostgreSQL service (initdb, stop etc. fail to work).
If not whitelisting the 'postgres' account, should we add a note into the guide, that applying remediation will make PostgreSQL service fail to work? (to prevent possible future customer's bug reports due this when remediated)
Since 'mysql' is working even with disabled shell access, should we check with PostgreSQL upstream if it would be possible modify the postmaster's behaviour it to be able to initdb / stop / etc. even with disabled shell access for 'postgres' user?
Comments appreciated.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] like allow the 'postgres' account to have shell defined under particular /etc/passwd row _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-------------------------
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 12/10/13, 10:06 AM, peake@hipkllc.com wrote:
I have experienced the same as Jan on my build that uses postgres.
Leland, you are saying I can just lock the account, and it will pass the check? If so I will give this a try here, as I didn't even think of trying that.
You'll still get a fail on a STIG scan. The OVAL checks for the shell. Here's the associated OVAL code: https://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/input/c...
On 12/10/13, 9:41 AM, Steinke, Leland J Sr CTR DISA FSO (US) wrote:
If the account is locked, rather than disabled via shell, this problem vanishes.
So are you saying we can finally remove CCE-26966-2, "Ensure that System Accounts Do Not Run a Shell Upon Login," from the STIG as it's known to break things? ;)
http://people.redhat.com/swells/scap-security-guide/RHEL6/output/rhel6-guide...
scap-security-guide@lists.fedorahosted.org