Page MenuHomeFreeBSD

[net0211] Add new capabilities; restrict what can be done in a jail.
ClosedPublic

Authored by adrian on Jul 12 2020, 3:17 AM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 14 2024, 6:16 PM
Unknown Object (File)
Jan 8 2024, 5:32 AM
Unknown Object (File)
Dec 22 2023, 11:10 PM
Unknown Object (File)
Dec 22 2023, 7:16 AM
Unknown Object (File)
Nov 8 2023, 12:27 PM
Unknown Object (File)
Nov 6 2023, 10:42 PM
Unknown Object (File)
Nov 5 2023, 3:59 PM
Unknown Object (File)
Nov 4 2023, 5:16 AM

Details

Summary
  • Split the MANAGE privilege into MANAGE, SETMAC and CREATE_VAP. + MANAGE is everything but setting the MAC and creating a VAP. + SETMAC is setting the MAC address of the VAP. Typically you wouldn't want the jail to be able to modify this. + CREATE_VAP is to create a new VAP. Again, you don't want to be doing this in a jail, but this DOES stop being able to run some corner cases like Dynamic WDS (DWDS) AP in a jail/vnet. We can figure this bit out later.

This allows me to run wpa_supplicant in a jail after transferring
a STA VAP into it. I unfortunately can't currently set the wlan
debugging inside the jail; that would be super useful!

Note that running wpa_supplicant in a jail requires lo0 to be up
and have an IPv4 address otherwise it doesn't get the routing
socket message size - it uses NET_RT_DUMP to do so. That should
be fixed in a later change.

Test Plan
  • STA mode, AR9380, in vnet/jails.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 32265
Build 29755: arc lint + arc unit

Event Timeline

About the commit message.

"capabilities" are something different in our kernel.
I'd really try to stick with the term "privileges" in the description.
The entire "note that ...lo0 .. " has nothing to do with this change at all so shouldn't be there.

sys/kern/kern_jail.c
3069

We normally do not leave comments here for any of these. Sadly we don't have a good man page apart from a wlan one maybe to document this. It'll be in the commit message at least, which is good.

sys/net80211/ieee80211_ioctl.c
252

This seems unrelated noise and should not be part of that commit.

sys/sys/priv.h
356

it is VAP_* for the others, can this one also be VAP_CREATE?

bz requested changes to this revision.Jul 13 2020, 8:27 AM
This revision now requires changes to proceed.Jul 13 2020, 8:27 AM
sys/net80211/ieee80211_ioctl.c
252

Yeah, this is a left-over from other work in this tree.

sys/sys/priv.h
356

The others operate on vaps, this one doesn't technically operate ON a vap, it ends up making one. I didn't know how else to express that clearly.

Updated from feedback

This revision is now accepted and ready to land.Jul 19 2020, 1:50 PM

I think this broke the build on r363327 with if_an.

To unbreak, I opened D25723.

In D25630#569409, @neel_neelc.org wrote:

I think this broke the build on r363327 with if_an.

Maybe we should just retire wi and an? They are no longer relevant.

In D25630#569426, @imp wrote:
In D25630#569409, @neel_neelc.org wrote:

I think this broke the build on r363327 with if_an.

Maybe we should just retire wi and an? They are no longer relevant.

amusingly I'm thinking of resurrecting wi's 802.3 path because - get this - the 11ac/11ax hardware is trending towards 802.3 offloaded data paths, and it's SUPER EASY to test that with wi(4).

Our wi(4) was just rewritten to use the raw mode for WPA support but didn't include the firmware reflashing bits.

Lemme think about it. I don't even know if I have an(4) hardware anymore.