Bug 2207562
| Summary: | sos report --clean doesn't obfuscate all MAC addresses. | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Pranav Lawate <plawate> | |
| Component: | sos | Assignee: | Pavel Moravec <pmoravec> | |
| Status: | CLOSED ERRATA | QA Contact: | Daniel Záležák <dzalezak> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 8.5 | CC: | agk, dzalezak, jcastillo, jjansky, mhradile, pgm-rhel-tools, plambri, rmetrich, sbradley, theute, toneata | |
| Target Milestone: | rc | Keywords: | Triaged, ZStream | |
| Target Release: | --- | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | sos-4.5.5-2.el8 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 2221099 (view as bug list) | Environment: | ||
| Last Closed: | 2023-07-26 08:37:56 UTC | Type: | Bug | |
| 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: | 2221099 | |||
Nice finding! (In reply to Pranav Lawate from comment #1) > ~~~ > # aa:bb:cc:dd:ee:ff avoiding ipv6 substring matches > IPV4_REG = ( > 28 r'((?<!([0-9a-fA-F\'\"]:)|::)(([^:\-])?([0-9a-fA-F]{2}([:-])){5}' > 29 r'([0-9a-fA-F]){2}(\'|\")?(\s|$)))' > 30 ) > ~~~ > > The data set to match the partition: > ~~~ > link/ether 52:54:00:3a:b2:a1 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 > maxmtu 65535 > > 52:54:00:3a:b2:a1 dev virbr0 vlan 1 used 2479/2479 master virbr0 permanent > > ATTR{address}== '52:54:00:8b:f9:81', NAME="eth0" <---- Missed >  > The result of SIOCGIFHWADDR is type 1 52:54:00:8b:f9:81. <---- Missed > >  > "net.interface.enp1s0.mac_address": "52:54:00:8b:f9:81", <---- Missed >  > entry=NULL-0000:02:00.0-eno3-52:54:00:8b:f9:81-igb↵ <---- Missed >  > <mac address='52:54:00:3a:b2:a1'/> <---- Missed > ~~~ > > > The issue lies with `?(\s|$)` this only matches with whitespaces and end > of line. > If we modify it to > `?(\/|\,|\-|\.|\s|$)` <-- Exclusively matching forward slash, comma, > hyphen, fullstop along with blank space and End of line (NOT future proof) > or > `?(\D)` <--- Matching non-Digit patterns , matches with anything > that isn't a digit including white space and End of line > or > `?(\W)` <--- Matching non-Word patterns , matches with anything that > isn't a word including white space and End of line The '?' applies to the preceding (\'|\"), meaning "address can be wrapped by either quotation mark". What can (or cant) follow *after* an address? Just blank space or newline (like now) is not sufficient. Non-word (or on-digit) pattern isnt correct since it treats The result of SIOCGIFHWADDR is type 1 '00:50:56:fd:51:40'x as a match, while: The result of SIOCGIFHWADDR is type 1 00:50:56:fd:51:40 as a non-match. (how to test: python3 import re IPV4_REG = '((?<!([0-9a-fA-F\\\'\\"]:)|::)(([^:\\-])?([0-9a-fA-F]{2}([:-])){5}([0-9a-fA-F]){2}(\\\'|\\")?(\W)))' re.findall(IPV4_REG, "The result of SIOCGIFHWADDR is type 1 00:50:56:fd:51:40", re.I) ) The > `?(\/|\,|\-|\.|\s|$)` <-- Exclusively matching forward slash, comma, > hyphen, fullstop along with blank space and End of line (NOT future proof) sounds to work well in all use cases I tested, though I dont like much the explicit enumeration of allowed characters. But it seems the best / working. Jake, any preferences? The biggest consideration here is to ensure that we continue to ignore substring matches within IPv6 MAC address strings. The only concern I have is matching on `-` characters, as sometimes mac addresses are written with dashes instead of colons - beyond that while it's not ideal, I don't have a better solution than the other explicit matches. *** Bug 2221099 has been marked as a duplicate of this bug. *** 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 (sos bug fix and enhancement update), 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-2023:4279 |
Description of problem: Sos reporit Version-Release number of selected component (if applicable): # cat etc/redhat-release Red Hat Enterprise Linux release 8.5 (Ootpa) # rpm -q sos sos-4.5.1-3.el8.noarch How reproducible: 100% reproducible Steps to Reproduce: 1. Run `sos report --clean` 2. Extract the /var/tmp/sosreport file generated 3. Find mac address inside various log files that is not obfuscated. # find /sosreport..<remaining path> -type f -exec grep <MAC_Address> {} \; Actual results: MAC address is still found even when --clean was used. Expected results: All occurances of MAC address should be obfuscated. Additional info: On my test machine, Without obfuscation 12 occurrences found while using --clean removes only 6 of those.