Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
RFE as requested by one of our potential customers.
Description of problem:
Although satellite provides openscap to help ensure that managed nodes are in compliance with PCI-DSS / STIG and many other standards, it would be really nice if we could get compliance certification for Satellite itself.
We do this for other products, and I think it would be really beneficial for satellite to have the same certifications.
Ideally, PCI-DSS would be the first, possibly CIS and STIG.
Version-Release number of selected component (if applicable):
Currently missing in 6.0.x, 6.1.x and 6.2.x. Would be great if we could get this in 6.3.x
The list of government certifications for all products is here.
https://access.redhat.com/articles/2918071
This is biting us at the moment. Does anyone know which particular STIG is actually causing this failure? We have ability to apply for exceptions to particular STIGs, but need to know which one to disable or change in order to do so. So I don't see this as an all or nothing issue.
For this particular issue it appears to be an SELinux denial. Because one of the STIG requirements is `SELINUX=enforcing`, while `satellite-installer` is running, it appears several files get created for `qpidd` which don't have the correct context.
```
# ausearch -m avc -c qpidd
type=PROCTITLE msg=audit(1535719817.865:2658): proctitle=2F7573722F7362696E2F7170696464002D2D636F6E666967002F6574632F717069642F71706964642E636F6E66
type=SYSCALL msg=audit(1535719817.865:2658): arch=c000003e syscall=4 success=no exit=-13 a0=7ffc3a4deba0 a1=7ffc3a4deb10 a2=7ffc3a4deb10 a3=2 items=0 ppid=1 pid=2821 auid=4294967295 uid=996 gid=994 euid=996 suid=996 fsuid=996 egid=994 sgid=994 fsgid=994 tty=(none) ses=4294967295 comm="qpidd" exe="/usr/sbin/qpidd" subj=system_u:system_r:qpidd_t:s0 key=(null)
type=AVC msg=audit(1535719817.865:2658): avc: denied { getattr } for pid=2821 comm="qpidd" path="/var/lib/qpidd/.qpidd/qls/dat2/__db.001" dev="dm-5" ino=16954472 scontext=system_u:system_r:qpidd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
```
Notice `/var/lib/qpidd/.qpidd/qls/dat2/__db.001` has `unlabled_t`
A simple `restorecon` fixes it
```
# restorecon -R /var/lib/qpidd
```
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.