Page MenuHomeFreeBSD
Differential D56267

wpa: Fix permission leakage when updating configuration file
Needs ReviewPublic
Actions

Authored by aokblast on Mon, Apr 6, 6:35 AM.
Tags
None
Referenced Files
F151923967: D56267.diff
Sat, Apr 11, 1:37 PM
Unknown Object (File)
Sat, Apr 11, 9:33 AM
Unknown Object (File)
Tue, Apr 7, 8:04 AM
Unknown Object (File)
Mon, Apr 6, 1:16 PM
Unknown Object (File)
Mon, Apr 6, 7:32 AM
Subscribers
imp

Details

Reviewers
bz
cy
Summary

In FreeBSD, wpa_supplicant.conf is installed with 0600 by default.
However, after calling UPDATE_CONFIG command, the new created tmpfile
with default permision (0644) will overwrite this behavior. We use chmod
before renaming to prevent such leakage.

Diff Detail

Repository
rG FreeBSD src repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 72107
Build 68990: arc lint + arc unit

Event Timeline

aokblast created this revision.Mon, Apr 6, 6:35 AM
Herald added a subscriber: imp. · View Herald TranscriptMon, Apr 6, 6:35 AM
Harbormaster completed remote builds in B71978: Diff 174951.Mon, Apr 6, 6:35 AM
aokblast requested review of this revision.Mon, Apr 6, 6:35 AM
aokblast added a reviewer: bz.Mon, Apr 6, 6:35 AM
bz added a reviewer: cy.Mon, Apr 6, 4:56 PM

Cy is maintaining wpa, so add him to reviewers.

bz added a comment.Mon, Apr 6, 5:03 PM

I wonder multiple things:
(a) is this a problem with umask for the wpa_supplicant process and could be fixed in the startup script for the general FreeBSD case for as long as a user does not run things manually?
(b) should the code not check the original config file permissions and apply these? (generic solution?)
(c) if there is no file, hard coding these as for android would need #ifdef around.

aokblast updated this revision to Diff 175036.Tue, Apr 7, 12:25 PM

Apply permission by honoring original permission

Harbormaster completed remote builds in B72012: Diff 175036.Tue, Apr 7, 12:25 PM
aokblast added a comment.Tue, Apr 7, 12:27 PM
In D56267#1287651, @bz wrote:

I wonder multiple things:
(a) is this a problem with umask for the wpa_supplicant process and could be fixed in the startup script for the general FreeBSD case for as long as a user does not run things manually?

No, other wpa consumer, like the wutui from GSoC 2025 can trigger this.

(b) should the code not check the original config file permissions and apply these? (generic solution?)

Yes, you are right. Fix it now! Thanks!

(c) if there is no file, hard coding these as for android would need #ifdef around.

Ok.

aokblast updated this revision to Diff 175229.Fri, Apr 10, 2:45 PM

Move the check beforehead

Harbormaster completed remote builds in B72107: Diff 175229.Fri, Apr 10, 2:45 PM

Revision Contents
Changeset List

PathSize
contrib/
wpa/
wpa_supplicant/
5 lines

Diff 175229

View Options

contrib/wpa/wpa_supplicant/config_file.c

Loading...