I agree with keeping the bash remediations. I make use of this projects
bash remediations as a reference for my project...sort of a second opinion.
Like Trevor said in #3, Ansible is not a great prospect to use in
production environments on secured networks. Automated, remote, privileged
execution isn't a concept that's easy to get past the cyber security
folks. There is a catch-22 with this in the DoD arena though...We're all
required to overlook RHEL-06-000529/RHEL-07-010340 with regard to allowing
ACAS to run scans on our systems with unchallenged privilege escalation. I
tried to propose using SSH keys, SSH Agent, and pam_ssh_agent_auth, but we
can't find anyone involved with ACAS who can speak intelligently about the
topic.
Anyway, the project I work on is similar to Trevor's in that we use
Puppet. Since Puppet is an agent process, which runs as root, and is
secured with client ssl certificates, the "server" is never doing a remote
execution. The agent requests it's configuration from the server, the
server authenticates the agent by the ssl certificate and provides the
data. Most of you probably know this already.
P.S. Trevor's SIMP project is way cooler than mine, especially if you
appreciate stylish, elegant, functional puppet modules! My project is more
like a rusty old ford truck - it gets the job done, but don't expect better
than 10 gallons to the mile.
--Sean
On Fri, Aug 4, 2017 at 9:34 AM, Trevor Vaughan <tvaughan(a)onyxpoint.com>
wrote:
There are a few other considerations that I would like to mention.
1) Ansible is **NOT** agentless. It needs SSH to be an agent. SSH should
not be a requirement for a functional system since, in many production use
cases, it is an unnecessary service. And, being an unnecessary service, per
policy, SSH should not be running.
2) Ansible local is fine and can be run through many means, but as
mentioned by Wesley, RHEL6 isn't much fun.
3) Having any account that has the power that Ansible requires should be
isolated away from the rest of your production environment. IIRC, we
discourage users from running privileged commands as root without explicit
sets of sudo rules in place to constrain them. In theory, all sets of
Ansible playbooks should come with an associated set of 'sudo' rules to be
installed on the system. Additionally, use of Ansible should be constrained
to a bastion that restricts users from running in parallel so that auditing
is solid. Perhaps this could be a set of dynamically created containers
that churn out independent audits?
Anyway, omnipotent SSH accounts were always up for tight scrutiny and
there really needs to be an addition to the SSG targeting Ansible as part
of the Red Hat stack since it's fundamentally just SSH in a loop.
Thanks,
Trevor
On Thu, Aug 3, 2017 at 7:27 AM, Wesley Ceraso Prudencio <
wcerasop(a)redhat.com> wrote:
> We discussed this idea internally as well, and we came up with the
> following reasons to not go further with it:
>
> - why remove something we already have? there is no harm in keeping it
> - ansible is problematic on rhel6 due to python version
> - --remediate would stop working
> - bash is mentioned in the XCCDF spec, ansible @system is something we
> made up
> - in RHEL8 we could have ansible as default system for remediation
>
> ----- Original Message -----
> From: "Shawn Wells" <shawn(a)redhat.com>
> To: scap-security-guide(a)lists.fedorahosted.org
> Sent: Wednesday, August 2, 2017 1:40:18 AM
> Subject: Re: Time to drop bash remediations?
>
>
>
> On 8/1/17 7:25 PM, Gabe Alford wrote:
> > I say we keep bash scripts as other distros will probably need them.
> > Plus, I would think that we would want to handle environments where
> > ansible will never be used.
>
> Psh.... what other Linux distros? =P
>
> You're totally right. And that definitely means we need to continue
> carrying bash remediations.
> _______________________________________________
> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
>
rahosted.org
> To unsubscribe send an email to scap-security-guide-leave@list
>
s.fedorahosted.org
> _______________________________________________
> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
>
rahosted.org
> To unsubscribe send an email to scap-security-guide-leave@list
>
s.fedorahosted.org
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788 <(410)%20541-6699>
-- This account not approved for unencrypted proprietary information --
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.
fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@
lists.fedorahosted.org