[kismac] Re: KisMAC 0.05d

From: Brad Knowles <brad.knowles@xxxxxxxxx>

To: kismac@xxxxxxxxxxxxx

Date: Wed, 23 Jul 2003 21:15:43 +0200

At 8:38 PM +0200 2003/07/23, Michael Rossberg wrote:
>> object to it being installed setuid! I don't think there is a setuid
>> script alive that couldn't be subverted by someone sufficiently
>> motivated.
>
> i do not believe in security by obscurity...
This is not a "security through obscurity" issue. This is an
issue where even the most paranoid scripts can be subverted, where
the same level of paranoia applied to a binary program can be made
relatively secure.
There's a reason why Perl has "taint" mode for setuid scripts,
and even that doesn't fully resolve the issue.
On a philosophical level, when you go to do a tcpdump on an
interface, you need to be root. If you're not already root when
running the program, then you need to `su` or `sudo` to get root.
IMO, the same logic should apply to KisMac -- don't install setuid at
all, and if you need that level of privilege when you execute, then
ask for them through the system-provided (presumably secure) methods,
and only at runtime.
I don't want anyone, anywhere, installing setuid scripts on my
machine. I've got twenty years of experience using Unix and the
Internet, and I've seen the really bad things that can happen when
setuid scripts run amok. Hell, I don't really want setuid binaries
on my machine, but for some of them, I don't have a choice.
This is a case where I don't want either setuid scripts or
binaries being installed on my machine -- ask me for my password at
runtime if you need to, but don't assume more privilege than
necessary during the installation.
>> Not pretty. Version 0.05d is definitely not something I will be
>> using. I'll test it out with the other drivers and the other cards,
>> but that's it.
>
> do you have some logs for me?
Which logs do you want, and where should I send them?
BTW, when I first installed 0.05d, it wouldn't run from the icon
on the dock -- I had to double-click on the original file icon
itself. After rebooting, that problem cleared itself up.
In both cases (before and after rebooting), after selecting the
driver I wanted to load and then clicking on "Scan", several seconds
went by when nothing appeared to happen. Only then did I get a
dialog box asking me if I really wanted to load the Viha driver, or
telling me "Working....". There really should be some immediate
feedback, regardless of how long it may or may not take to perform
the necessary action.
In all cases, the system was not able to load the Viha, MacJack,
or the new AiroJack driver, and no scanning was possible.
In some cases, when I tried to quit the application, it would try
to re-load the Viha, MacJack, or AiroJack driver instead of the
original application driver (which had to be cancelled) before
quitting. In one case, 0.05d completely locked my machine up solid,
requiring that I pull the plug and pop the battery out, then turn the
machine back on.
Definitely not a pretty sight.
> i would love to support such cards. but the problem is, that we cannot
> get a hold of their documentation. they are equal to those airport
> extreme cards. and exactly this is the problem. so i cannot do anything
> to support them currently :o/
IIRC, there have recently been some open source Linux drivers
released for the Broadcom chipset. Basically, they had to
reverse-engineer everything. Have you seen these?
--
Brad Knowles, <brad.knowles@xxxxxxxxx>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)