Need appropriate SELinux type enforcement profile to work on hardened EL7 instances

[ferricoxide]

Our compliance requirements include need for signed RPMs that are compatible with SELinux in targeted enforcement-mode. Had put together a process to download SRPMs from the Amazon Linux 2 AMIs whenever the "new AMI" SNS notice would hit. Found that ec2-instance-connect SRPM started showing up in the 20190612 AMI. After repackaging for Enterprise Linux 7, found that service wasn't working with our AMIs. After some investigation, determined issue was lack of SELinux compatibility. Used the AVC denials to put together a provisional SELinux exclusion.

Currently am using the following in my (ad hoc) UserData to allow use of the ec2-instance-connect (but would obviously prefer this just live in the RPM):

# Write an uncompiled SELinux type-definition to disk
cat > /root/instance-connect.te << EOF
module instance-connect 1.0;

require {
        type ssh_keygen_exec_t;
        type http_port_t;
        type sshd_t;
        class process setpgid;
        class tcp_socket name_connect;
        class file { execute execute_no_trans open read };
}

#============= sshd_t ==============

#!!!! This avc can be allowed using one of the these booleans:
#     authlogin_yubikey, nis_enabled
allow sshd_t http_port_t:tcp_socket name_connect;
allow sshd_t self:process setpgid;
allow sshd_t ssh_keygen_exec_t:file { execute execute_no_trans open read };
EOF

# Compile and SELinux module for EC2 Instance Connect
checkmodule -M -m -o /root/instance-connect.mod /root/instance-connect.te
semodule_package -o /root/instance-connect2.pp -m /root/instance-connect.mod
semodule -i /root/instance-connect2.pp

Am looking to submit a PR, but wanted to know if the above (the policy-def in the HERE document; the rest is just a way to activate it outside of a managed packaging) is sufficient. The PR would include the compiled policie files and appropriate %post script (updates) to ensure they're activated. Is there a preference on priority level that they should be activated to (i.e., is 400 ok, or would there be a preference for a different level?).

[LordAlfredo]

Hm, in testing I noticed that when sshd invoked the AuthorizedKeysCommand that fingerprint calculation was now returning an empty string. Removing the cut (ie, so there was no piping) caused the set -e to capture an exit status 139 from ssh-keygen. Manually invoking the command and/or switching sshd_t's domain to permissive let it succeed, so it's definitely a missing allow somewhere.

I can say for certain it's not on ssh_keygen_t/ssh_keygen_exec_t's domains - flipping those to permissive doesn't change behavior at all.

[ferricoxide]

K. I'll dig back through. Those were the ones that were creating AVCs on my CentOS 7.6 with this week's patches applied.

[LordAlfredo]

Might be sufficient on the 7's then, I was testing on a fresh RHEL8 instance. I'd prefer if we can figure out a single succifient entry rather than needing to split things more.

[ferricoxide]

Unfortunately, my customer only authorizes EL7 (and EL6, euw) for their cloud-based deployments. My plans are to keep ahead of the curve and move to EL8 long before the STIGs come out. However, I'm trying to wait to switch till I've re-upped my RHCE on EL7 (and also prefer to wait until I can upgrade my VPS to CentOS 8).

Long-winded way of offering to help with EL7 stuff pending any future ability to help with EL8. :)

[ferricoxide]

Just trying to stay abreast of things: any additional input (etc.) you need from me?

[LordAlfredo]

Aha! Did a bit of digging with audit.log and found the issue. On EL8 the ssh-keygen invocation was failing on map permission - adding it to the file type and the ssh_keygen_exec_t:file domain got things working.

[n0coast]

I've run into this on Amazon Linux 2 as well, with selinux enabled instance connect fails - with the definition @ferricoxide provided at the top of the thread applied instance connect works again.

For the moment I can bake this into my AMIs, but it'd be great if this was just included with the rpm - or at least noted in documentation.

As a side note the only indication of this issue is a message in /var/log/secure: sshd[4287]: error: AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys ec2-user SHA256:...... failed, status 7

As of early November '19 if you are running this on AZ2 you'll need to systemctl enable rhel-autorelabel (which is owned by the initscripts rpm).

[wunderhund]

Also just ran into this on Amazon Linux 2 while testing a CIS-benchmarked image. Thanks @n0coast for posting a comment with that error message, I don't know how long it would've taken me to find this otherwise!

[LordAlfredo]

I should clarify, while this policy serves as a good reference we are not currently working on including it the SELinux policy into the package itself. There are broader implications to consider about changing the sshd security policy (particularly granting it curl and ssh-keygen access).

That said, RHEL support is high on our radar and we are evaluating our options for support.

[ferricoxide]

Finally got tasked to create our RHEL8 and CentOS8 AMIs for a couple of our customers. So, need to revisit the status of this. I can bake creation of policies into our AMI-generation process …but would be so much easier if the packaging of InstanceConnect just included things.

Any anticipated timeframe, yet, for sorting the SELinux policies out and including them in the RPM?

[acdha]

@ferricoxide Thanks for including the error message in a high-quality issue – I ran into this while searching through SELinux logs and while I was able to resolve it by having Ansible remove the ec2-instance-connect because this particular project doesn't use public IPs that won't be true of some of the other projects which I support.

[wcgcoder]

What a bummer this wasn't incorporated into the project. Luckily you made this issue and I was able to incorporate it into my AMI build.

[wombelix]

I work on packaging ec2-instance-connect for Fedora and later EPEL. It will contain a proper SELinux profile. At this moment the package review is ongoing: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2274150