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(a)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(a)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(a)mail.mil (gov't)
lsteinke(a)tapestrytech.com (com'l)
-----Original Message-----
From: scap-security-guide-bounces(a)lists.fedorahosted.org [mailto:scap-
security-guide-bounces(a)lists.fedorahosted.org] On Behalf Of Jan
Lieskovsky
Sent: Tuesday, December 10, 2013 5:14 AM
To: scap-security-guide(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide