Description of problem: When flushing the SAD and SPD, we do not check for authorization before deleting the SA or Security Policy. Version-Release number of selected component (if applicable): lspp 69 kernel and current upstream kernel How reproducible: All the time. Steps to Reproduce: 1.create a new type that is NOT in the domain attribute. 2. do setenforce 0 3.create an SA and/or ipsec policy manually with this new type as part of the security context and add it to the kernel. 4. setenforce 1 5. do a "setkey -F" and "setkey -FP". 6. do a "setkey -D" and "setkey -DP". databases have been flushed and should not have been since new type does not have setcontext permission. Actual results: Databases flushed. Expected results: Should not have been flushed. Additional info: Already have a patch. Plan to send upstream tomorrow morning. Will attach to this bugreport.
Created attachment 150672 [details] Patch adds security check when flushing spd and sad.
Was this patch sent to netdev? I was just looking at it for the LSPP backport and noticed that this patch won't audit failures. If we are going to make the security check I'd think we would want to audit both sucess and failure...
I'm going to pull a form of this patch into lspp.70 since I think it will still be able to help flush out problems the new hook might cause, but I don't think this patch is the acceptable solution.
I thought we audited when a delete or add succeeded or failed. In this case, the delete is not attempted if no permissions. I did send this to netdev. There is some concern about checking each entry in a flush and should the security layer be doing this. I have included the selinux list for security advice.
Redoing this patch upon suggestions for improvement made on mailing list. Will add to the bugreport once it has been improved and accepted.
I would call a selinux permission check denial an 'attempt that failed' myself. Seems to be if you go with your patch we need to save the return value from the security call and pass that as the 'result' into the audit hook. Thus we audit that someone tried to change the MAC policy but either succeded or failed. With your patch there would be no audit record that someone without permissions tried to flush right? Or do we claim that an AVC denial is enough? If so we could rework/clean a log of the xfrm audit stuff and maybe throw out the result field of the audit function altogether.
This was built into lspp.71. Joy, does this problem test OK now? Thanks.
This tested out successfully in the 72 kernel.
in 2.6.18-27.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
A fix for this issue should have been included in the packages contained in the RHEL5.1-Snapshot3 on partners.redhat.com. Requested action: Please verify that your issue is fixed as soon as possible to ensure that it is included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. More assistance: If you cannot access bugzilla, please reply with a message to Issue Tracker and I will change the status for you. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager.
A fix for this issue should have been included in the packages contained in the RHEL5.1-Snapshot4 on partners.redhat.com. Requested action: Please verify that your issue is fixed *as soon as possible* to ensure that it is included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message to Issue Tracker and I will change the status for you. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager.
A fix for this issue should have been included in the packages contained in the RHEL5.1-Snapshot6 on partners.redhat.com. Requested action: Please verify that your issue is fixed ASAP to confirm that it will be included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message to Issue Tracker and I will change the status for you. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager.
A fix for this issue should have been included in the packages contained in the RHEL5.1-Snapshot7 on partners.redhat.com. Requested action: Please verify that your issue is fixed ASAP to confirm that it will be included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message to Issue Tracker and I will change the status for you. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager.
A fix for this issue should be included in the packages contained in RHEL5.1-Snapshot8--available now on partners.redhat.com. IMPORTANT: This is the last opportunity to confirm that your issue is fixed in the RHEL5.1 update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message to Issue Tracker and I will change the status for you. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0959.html