[SERVER-47108] Support automatic redaction of Status and DBException by the logging system Created: 25/Mar/20  Updated: 11/Jan/23  Resolved: 11/Jan/23

Status: Closed
Project: Core Server
Component/s: Logging
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Backlog - Security Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Server Security
Sprint: Security 2020-04-20, Security 2020-05-04, Security 2020-05-18, Security 2020-06-01, Security 2020-06-29
Participants:

 Description   

We are supposed to redactStatus or DBException prior to logging it, if it is possible that this entry may contain some sensitive information (e.g., unencrypted user data). This is a bit error prone, because it requires engineers to remember to add redact.

It would be nice if the new V2 logging system automatically did this. With a disclaimer that I only thought about this for 15 seconds, where is what I am imagining:

Somehow change the traits of CustomAttributeValue to check whether it is of type Status or DBException and instead of calling T::toString to actually call redact(T::toString()). My reasoning was that if this framework knows that there's a method toString it must also know that there is a specific type.



 Comments   
Comment by Andy Schwerin [ 01/Jun/20 ]

I think that's a smart idea, sara.golemon!

Comment by Sara Golemon [ 01/Jun/20 ]

Redacting full statuses in all log messages is going to be too aggressive, but I'd like to pivot this ticket into a larger project (possibly an epic?) of structuring Status (to fit in with structured logs).  Naïvely, I think we can redesign Status to have a fixed message (and possibly ID) with a bag of attributes similar to our LOGV2 structure.  A status propagated to a log message could then have its attribute bag (optionally) redacted while leaving the message text (and ID) in place.  We could also provide a no-redact mechanism for data which are known to not be sensitive.

This is a conversation which deserves to have a number of other stakeholders in the room before we move forward on it in any way. 

Generated at Thu Feb 08 05:13:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.