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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

Reply via email to