Bug 1830497

Summary: SR-IOV operator is in openshift.io/run-level 1 and bypassing SCC
Product: OpenShift Container Platform Reporter: Mark McLoughlin <markmc>
Component: NetworkingAssignee: Peng Liu <pliu>
Networking sub component: SR-IOV QA Contact: zhaozhanqi <zzhao>
Status: CLOSED ERRATA Docs Contact:
Severity: medium    
Priority: unspecified CC: bbennett
Version: 4.5   
Target Milestone: ---   
Target Release: 4.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-13 17:34:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1805488, 1966621    

Description Mark McLoughlin 2020-05-02 08:47:18 UTC 
The openshift-sriov-network-operator namespace is labelled with openshift.io/run-level: "1"

From bug #1805488:

Run-level 1 bypasses SCC, but many components have no need for that (are less secure as a result).  Every component that does not need to be up before SCC starts should be in either the anyuid or restricted SCC profile so they get a stable SELinux label.

Because these components are running without the appropriate restrictions, the security profile of these core components is weaker than it should be.

All platform components that can run without a run level MUST do so, and use anyuid or restricted unless they can make a case for host network or privileged. Those components should be granted access to the protected SCCs.

Each component listed here must be reviewed to determine whether it must be in run-level 1 or not, and if not, the label should be removed and appropriate SCC bindings created.


If the SR-IOV operator has a genuine need to run at this level, it would at least be helpful to briefly document the reason for that as a comment above the label.
Comment 1 Peng Liu 2020-05-06 12:38:08 UTC 
The SR-IOV operator is in charge of configuring the SR-IOV network devices of the host. So hostNetwork and privileged is a must-have for these tasks. However, I think the privileged SCC should be sufficient.
Comment 4 zhaozhanqi 2020-05-13 08:54:06 UTC 
Verified this bug on 4.5.0-202005111717

1. create namespace openshift-sriov-network-operator
2. cat >og.yaml <<EOF
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
  - openshift-sriov-network-operator
EOF | oc create -f -

3. setup the sriov operator with above version
4. Create sriovnetworknodepolicy
5. Create sriovnetwork
6. Create test pod works well.
Comment 5 errata-xmlrpc 2020-07-13 17:34:13 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:2409