The fix in bug 559709 changes how capabilities are checked in pci_read_config(). The new check does a raw capability comparison against the open file's credentials, and that bypasses lsm/selinux checking. Restore the lsm/selinux checking (while maintaining the new check against filp->f_cred).
Moved to rhel6.1 . Awaiting upstream direction before changing rhel6 (again).
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Created attachment 477924 [details] security: add task, cred and audit flag arguments to security_capable() Expand arguments of security_capable() to include all arguments that will be passed through to the underlying ->capable() callback. This makes security_capable() usable in a wider range of call sites.
Created attachment 477925 [details] pci: use security_capable() when checking capablities during config space read Eric Paris noted that commit de139a3 ("pci: check caps from sysfs file open to read device dependent config space") caused the capability check to bypass security modules and potentially auditing. Rectify this by calling security_capable() when checking the open file's capabilities for config space reads.
Those two patches don't compile together, but give the basic idea.
Created attachment 477941 [details] security: add cred argument to security_capable() Expand security_capable() to include cred, so that it can be usable in a wider range of call sites.
Created attachment 477942 [details] pci: use security_capable() when checking capablities during config space read Eric Paris noted that commit de139a3 ("pci: check caps from sysfs file open to read device dependent config space") caused the capability check to bypass security modules and potentially auditing. Rectify this by calling security_capable() when checking the open file's capabilities for config space reads.
Posted patches in Comment #15 and Comment #16 upstream
And patch in Comment #16 is buggy.
Created attachment 478746 [details] pci: use security_capable() when checking capablities during config space read This reintroduces commit 47970b1b which was subsequently reverted as f00eaeea. The original change was broken and caused X startup failures and generally made privileged processes incapable of reading device dependent config space. The normal capable() interface returns true on success, but the LSM interface returns 0 on success. This thinko is now fixed in this patch, and has been confirmed to work properly. So, once again...Eric Paris noted that commit de139a3 ("pci: check caps from sysfs file open to read device dependent config space") caused the capability check to bypass security modules and potentially auditing. Rectify this by calling security_capable() when checking the open file's capabilities for config space reads.
Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as an exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Hi Chris, Eric, Can you give some suggestion how to this bug. Thanks Suqin
Eric will provide the bug description, ack this bug first. suqin
steps to test: $ sudo sandbox cat /sys/bus/pci/devices/$DEVICE/config should generate an avc denying sys_admin.
Patch posted for internal review
Patch(es) available on kernel-2.6.32-241.el6
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The cred argument has been included in the security_capable() function so that it can be used in a wider range of call sites.
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. http://rhn.redhat.com/errata/RHSA-2012-0862.html