NetworkManager or Wifi-Radar?

[Grant McWilliams]

>
>
> Have fun pointing out the whole reliance on SUDO and other many
> mechanisms. Shoe-horning in another program named that with a
> possibility to replace the Binary regardless of it being the right one.
> and doing its bad work.
>
> At least with the proper groups and proper right assigned to them, you;d
> get MUCH less collateral damage.
>
> Don't forget that, SUID/GUID programs have their place, this may just be
> one of them.
>
> Come on, there are always two sides to this stuff. There are other
> alternatives as well.


:-) As much as I dislike SUDO at least you have more control and logging
over what the user does. At least you get to decide WHO gets to execute
wpa_gui as root. With SUID you have nothing, everyone IS root for that app
for all practical purposes. SUID needs to go away. I think on my servers I
wittle it down to about 9 SUID/SGID binaries left. When I get SELinux policy
modules created for them they'll be gone.

I realize that only one major disto and it's community variant uses SELinux
so that's not a solution for everyone. I don't know enough about AppArmor to
know if it could provide an SUID like Domain Transition decision policy.

If an SELinux policy was created for wpa_gui that had a wpa_gui_exec_t
domain and a wpa_gui_t domain that would have permissions to the relevant
network interfaces and sockets all you'd need is an allow policy to allow
wpa_gui_exec_t to transit to wpa_gui_t and allow unconfined_t execute
permissions. The whole thing could be constrained so that if it were
exploited it could only be used to edit wpa settings and nothing more. I
don't know that much about wpa_gui but if it reads files then it could be
forced to read files that it shouldn't and if it's SUID those files could be
ANY.

I'm sure this functionality is also in AppArmor so it would work in
Mandrake, Ubuntu, Sun Linux, and SuSE. I don't use most of those so I'm just
guessing.

Grant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.xfce.org/pipermail/xfce/attachments/20080613/556923b1/attachment.html>