Sean,

The scenario in your third paragraph can also be performed in a similar manor with ansible. Instead of the puppet agent communicating (ssl) with the master, ansible can fetch its configuration from whatever your source control is and execute locally. This can all be encrypted with your choice of a rotating cert setup. This could happen during startup or userdata, etc. Although, the rotation implementation is a handful and adds some complexity, especially with security folks, it is convenient and easy to manage expirations, rotations, and revocation....etc. 

Don't hold your breath on the ACAS situation haha. 

Matthew

On Fri, Aug 4, 2017 at 08:18 Sean <smalder73@gmail.com> wrote:
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@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@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@redhat.com>
To: scap-security-guide@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@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org



--
Trevor Vaughan
Vice President, Onyx Point, Inc

-- 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


_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org