Hmm, I remember being lambasted about not having NTP auth syncing enabled and chronyd doesn't appear to support this.
Thoughts?
Trevor
On Mon, Oct 6, 2014 at 12:09 PM, Jan Lieskovsky jlieskov@redhat.com wrote:
----- Original Message -----
From: "Gabe Alford" redhatrises@gmail.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Saturday, October 4, 2014 6:43:24 PM Subject: Re: RHEL 7 Direction
On Fri, Oct 3, 2014 at 5:08 PM, Shawn Wells < shawn@redhat.com > wrote:
On 10/3/14, 3:31 PM, Crawford, Nicholas P CTR USARMY CERDEC (US) wrote:
Greetings,
I had a couple of questions about the direction the RHEL 7 SSG will be going;
Particularly with the below new subsystems in 7;
gconf vs dconf (GNOME 2 vs GNOME 3)
Some applications do use gconf still, but I believe gnome requires dconf
in
RHEL7 since it is GNOME3. There is an existing pull request for
converting
most of the gconf settings to dconf.
Has there been a decision on how to check and remediate with dconf? iptables vs firewalld
iptables and firewalld conflict each other so one or the other
(preferably
firewalld).
+1 for firewalld due to ability to apply changes runtime (without disrupting existing connections) + due to concept of zones:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Has there been a decision on which method will go forward for check / remediation? chrony vs ntpd
No decision has been made on this as I am aware.
Comparison why chronyd might be preferred before ntpd:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Has there been a decision on which to use and which will go forward for check / remediation?
Actually, there hasn't been much conversation on this. Thanks for starting the conversation!
IMO, we should start with system defaults as first/primary goal, then enable secondary configs in future passes. aka, address firewalld first then iptables.
If we're able to get both done at the same time, then great -- but focus should be on system default first.
What does everyone think of such an approach?
+1
Commented on this in previous post.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/