[arch-general] Policy about packages and file capabilities
What's the policy about capabilities for executables in Arch packages? I'm asking since in my setup I'm running wpa_supplicant as the 'nobody' user, but I let it keep the NET_ADMIN and NET_RAW capabilities (excerpt from the .service file): User=nobody SupplementaryGroups=rfkill CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW The executable needs to have those capabilities on the executable in order to keep them when switching to user `nobody`, so I set them with: setcap 'cap_net_raw=ep cap_net_admin=ep' /usr/bin/wpa_supplicant I'd suggest (and send a patch) to add these capabilities in the next update to the package if that's acceptable. PS. wpa_supplicant is still not updated from version 2.3 which doesn't work with the wifi interface in the 4addr mode, bridged and with the -b option of wpa_supplicant. 2.4 and 2.5 work in that scenario. so I hope an update is due. -- damjan
On Mon, Nov 16, 2015 at 07:51:30PM +0100, Damjan Georgievski wrote:
What's the policy about capabilities for executables in Arch packages?
I _guess_ that capabilities are used to avoid SUID binaries when this is secure.
I'm asking since in my setup I'm running wpa_supplicant as the 'nobody' user, but I let it keep the NET_ADMIN and NET_RAW capabilities (excerpt from the .service file):
Read the caveat here: https://w1.fi/cgit/hostap/plain/wpa_supplicant/README . Basically, you'll need a special user/group for executing /usr/bin/wpa_supplicant. In general, why is this necessary? What kind of attack (besides DoS) is possible against wpa_supplicant? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
What's the policy about capabilities for executables in Arch packages?
I _guess_ that capabilities are used to avoid SUID binaries when this is secure.
well, also, unless you set capabilities on the executable a process can't have capabilities when a non-root process execs the executable -- that is until the ambient capabilities are supported in the kernel and systemd https://lwn.net/Articles/651052/ (afaik in 4.3)
I'm asking since in my setup I'm running wpa_supplicant as the 'nobody' user, but I let it keep the NET_ADMIN and NET_RAW capabilities (excerpt from the .service file):
Read the caveat here: https://w1.fi/cgit/hostap/plain/wpa_supplicant/README . Basically, you'll need a special user/group for executing /usr/bin/wpa_supplicant.
right, I think that too would need to be done in a proper package. I'd rather make it 750, and root/wpa_supplicant
In general, why is this necessary? What kind of attack (besides DoS) is possible against wpa_supplicant?
there have been buffer overflows etc. in wpa supplicant, not good for a root process. https://www.google.com/search?q=wpa_supplicant+CVE&ie=utf-8&oe=utf-8 -- damjan
On Mon, Nov 16, 2015 at 09:00:28PM +0100, Damjan Georgievski wrote:
What's the policy about capabilities for executables in Arch packages?
I _guess_ that capabilities are used to avoid SUID binaries when this is secure.
well, also, unless you set capabilities on the executable a process can't have capabilities when a non-root process execs the executable
Sure, that's what is done with the ping(8) binary.
I'm asking since in my setup I'm running wpa_supplicant as the 'nobody' user, but I let it keep the NET_ADMIN and NET_RAW capabilities (excerpt from the .service file):
Read the caveat here: https://w1.fi/cgit/hostap/plain/wpa_supplicant/README . Basically, you'll need a special user/group for executing /usr/bin/wpa_supplicant.
right, I think that too would need to be done in a proper package. I'd rather make it 750, and root/wpa_supplicant
Which means that the filesystem package should get modified?
In general, why is this necessary? What kind of attack (besides DoS) is possible against wpa_supplicant?
there have been buffer overflows etc. in wpa supplicant, not good for a root process. https://www.google.com/search?q=wpa_supplicant+CVE&ie=utf-8&oe=utf-8
But those CVEs are mostly denial of service... right? -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
participants (2)
-
Damjan Georgievski
-
Leonid Isaev