[SERVER-24780] Create audit log entry for setParameter command Created: 24/Jun/16 Updated: 13/Aug/16 Resolved: 28/Jul/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | 3.2.7 |
| Fix Version/s: | 3.3.11 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Andreas Nilsson | Assignee: | Andreas Nilsson |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Sprint: | Security 17 (07/15/16), Security (08/08/16) | ||||
| Participants: | |||||
| Linked BF Score: | 0 | ||||
| Description |
|
With the inclusion of setParameter support for LDAP authn/z parameters it is now technically possible to swap out the entire user database by switching LDAP server. This is a security event that should be audited. I propose we include an audit entry for all calls to setParameter. |
| Comments |
| Comment by Githook User [ 28/Jul/16 ] |
|
Author: {u'name': u'Andreas Nilsson', u'email': u'andreas.nilsson@mongodb.com'}Message: |
| Comment by Githook User [ 27/Jul/16 ] |
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}Message: Revert " This reverts commit 8d832327b805cfbf66e79cc0d1bc236cafe2846a. |
| Comment by Githook User [ 27/Jul/16 ] |
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}Message: Revert " This reverts commit a6fcab0cf4cad4bfee1d65ca2b9bfe0b69970a8f. |
| Comment by Githook User [ 27/Jul/16 ] |
|
Author: {u'name': u'Andreas Nilsson', u'email': u'andreas.nilsson@mongodb.com'}Message: |
| Comment by Githook User [ 27/Jul/16 ] |
|
Author: {u'name': u'Andreas Nilsson', u'email': u'andreas.nilsson@mongodb.com'}Message: |
| Comment by Andy Schwerin [ 24/Jun/16 ] |
|
My only objection is that it's one more path to test. |
| Comment by Eric Milkie [ 24/Jun/16 ] |
|
My concern with that is that it's not the default, so users would need to know that not only would they need to turn on authOk auditing, they might also need to add a filter to catch these types of events (and they would need to know that these types of events exist at all and might be valuable to audit). Auditing setParameter by default might be easier all around, and would avoid the extra overhead of turning on authOk auditing. |
| Comment by Andy Schwerin [ 24/Jun/16 ] |
|
What's wrong with auditing "authorization succeeded" on setParameter? Is there not enough information about the setParameter command in the log message for "authorization succeeded", or is it cumbersome in some other way? |
| Comment by Eric Milkie [ 24/Jun/16 ] |
|
I have no problem adding the command as a special audited event. |