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)

peake at hipkllc.com peake at hipkllc.com
Tue Dec 10 15:06:14 UTC 2013


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 at mail.mil (gov't)
lsteinke at tapestrytech.com (com'l)

> -----Original Message-----
> From: scap-security-guide-bounces at lists.fedorahosted.org [mailto:scap-
> security-guide-bounces at lists.fedorahosted.org] On Behalf Of Jan
> Lieskovsky
> Sent: Tuesday, December 10, 2013 5:14 AM
> To: scap-security-guide at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

-------------------------

_______________________________________________
scap-security-guide mailing list
scap-security-guide at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20131210/8e50d1fc/attachment-0001.html>


More information about the scap-security-guide mailing list