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.
- 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.
- Ansible local is fine and can be run through many means, but as
mentioned by Wesley, RHEL6 isn't much fun.
- 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.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@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
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.
- 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.
- Ansible local is fine and can be run through many means, but as
mentioned by Wesley, RHEL6 isn't much fun.
- 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 (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
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@lists.fedorahosted.org
-
Matthew Myers -
Sean