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: [email protected] [mailto:[email protected]] On Behalf Of Steinke, Leland J Sr CTR DISA FSO (US) Sent: Tuesday, December 10, 2013 9:41 AM To: [email protected] 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) [email protected] (gov't) [email protected] (com'l) > -----Original Message----- > From: [email protected] [mailto:scap- > [email protected]] On Behalf Of Jan > Lieskovsky > Sent: Tuesday, December 10, 2013 5:14 AM > To: [email protected] > 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 > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
