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)" <leland.j.steinke.ctr@mail.mil> 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