(bod and hartmans you were cc'd originally when I was looking at this so I thought you might be interested)
Here's an update on the gwireless-applet ITP. - gwireless depends on a couple of RedHat utilities that are not yet available o n Debian, "usermode" and "consolehelper". These are programs that prompt a morta l user to enter a passwd when attempting to run a program that needs root permissions(AFAICT). They're needed in onder to be able to invoke the gwireless configuration program from the gwireless applet(which calls iwconfig). Included below is a message from Sam Hartman with some comments. It looks like it would take quite a bit of effort to make this happen. I could modify the upstream source to not invoke the gui and just let the applet stand alone but.... - the applet only works in "Tiny" and "Ultra-Tiny" panel sizes making it much less useful. - The package "wavelan-applet" provides a better alternative to the working applet part of the functionality. - Upstream doesn't seem to be working on it anymore. So for now I'm not working on it anymore. I'll leave the ITP open in case others are interested in fixing the problems. -- Matt Taggart [EMAIL PROTECTED] ------- Forwarded Message To: Matt Taggart <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: PAM related packaging question From: Sam Hartman <[EMAIL PROTECTED]> Date: 09 Oct 2001 11:05:38 -0400 In-Reply-To: Matt Taggart's message of "Mon, 08 Oct 2001 22:49:11 -0600" usermode and consolehelper seem like kind of neat packages to have around. However it does seem that the Redhat implementation brings a new definition to the word sketchy. The same program is responsible both for running random programs and for changing users' passwords. This seems like a bad design choice. I really wish the userhelper program focused on being a good security gate rather than on being a good password changing tool. The consolehelper interface is reasonable. The split between consolehelper and userhelper is reasonable. The fact that userhelper has some functionality built in rather than always calling other programs is not reasonable. The fact that userhelper has gotten many of the classic things you can possibly get wrong in writing a setuid application wrong (environment variable handling as an example) is not good. I would tend to agree that packaging usermode in Debian without a full audit of the userhelper binary would be a bad idea. If someone qualified wants to do that audit then it seems reasonable to do. I'd certainly recommend that usermode completely sanitize its environment before passing control the root application. I don't like your solution of installing the wireless app setuid root very much. The problem with such solutions is that you are now running a program that does not expect to be its own security gate as a security gate. The program may not sanitize its environment; it may fail to do something else a setuid program needs to do. So either way you'd need to fully understand the issues involved in setuid program management well enough to audit a fair chunk of code. If you feel qualified to do the audit, I'd recommend working on usermode; it seems like a neat idea and the public interfaces are fairly well done. If not, you should probably find someone who has time to do such an audit before going forward with either option. I do not have such time and I'm not completely sure I'm qualified--most of my experience has been in network security protocol development rather than system security. - --Sam ------- End of Forwarded Message
