Bug#111842: gwireless-applet update
(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
taggart@debian.org
------- Forwarded Message
To: Matt Taggart <taggart@debian.org>
Cc: bod@debian.org
Subject: Re: PAM related packaging question
From: Sam Hartman <hartmans@mit.edu>
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
Reply to: