[kismac] Re: KisMAC 0.05d

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(+++)

Other related posts: