[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFFE: portmap 5-11

On Sun, May 29, 2005 at 02:37:07AM +0200, Javier Fernández-Sanguino Peña wrote:
>>>Anibal said:
>>>Javier pushed -10 as an important security improvement for desktop/laptop
>>>systems and I agree with him on that regard. Running portmap listening
>>>to the world on a desktop/laptop system is a considerable security
>Please note that I didn't push this patch that much. The fix was already 
>there (since portmap could be disabled through the configuration) I just 
>found it useful to be able to handle that through debconf.

Sorry about the use of 'pushed', I meant 'suggested' instead.

>On Thu, May 12, 2005 at 09:52:35PM -0400, Joey Hess wrote:
>>This is only my opinion, but debian systems have been running with these
>>problems for as long as there was debian; delaying the sarge release to
>>fix them does not seem worth it.
>I agree with Joey here. I meant to have that improvement on sarge but now I
>see that my postint needed a lot of improvement. The changes introduced by
>Anibal have made the situation worst, by adding a new configuration file
>you've forced an unnecesary deviation from sarge (/etc/default/portmap) to
>sid (/etc/portmap.conf).

RC bug #305505 was a direct result of your patch, it isn't your
fault anyway.

>This doesn't help at all. Sysadmins will get used
>to the first one after installing and hardening dozens of systems and 
>you've also obsoleted the documentation provided in the "Securing Debian 
>Manual" (which points [1] to the first one). If I want the documentation to 
>be applicable to different releases then I need to have it point to 
>different configuration files, confusing the reader in the end.

I'll request your input next time I plan a change like that.

>Worst of all, you are not preserving user changes at all since portmap's 
>current preinst says: 
>if [ "$1" = "upgrade" ]; then
>        # get rid of /etc/default/portmap
>        [ -e /etc/default/portmap ] && rm -f /etc/default/portmap
>This is going to be a big issue when upgrading from sarge -> etch since you 
>are _not_ managing the file at all!

I'll fix that problem. Please feel free to file a bug.

>Anibal, you could have fixed my postinst simply by having it check the
>MD5sum of the file and reject to ask any question (or make any change) if
>the user wasn't using the one originally provided by the package (i.e.  if
>it had been modified in any way). Also, the code needed to be changed so
>that the question was only asked in upgrades.
>IMHO the changes in -11 should be reverted. /etc/default/portmap _can_ be a
>conffile and can be modified by the postinst script just as long as changes
>by the user are preserved. Many packages do this already, for example,
>check out how this is done for /etc/X11/XF86Config in xserver-xfree86's
>config or, in a simpler way, for /etc/pam.d/passwd in passwd's preinst.
>Finally, by drastically changing with -11 what was introduced with -10 (new
>config file) and introducing new RC bugs you reduced to nil the changes of
>letting this go into sarge.

Please remember that RC bug #305505 was a direct consequence of your
patch. However, I take the blame as I'm the mantainer.

>In any case, please note that I do _not_ consider portmap running a system
>to be insecure, portmap has not had known vulnerabilities in years. I _do_
>consider *some* RPC services to be insecure. Exposing the portmapper
>exposes those too. Allowing users to restrict RPC services to the loopback
>interface reduces exposure not only of the portmapper itself but to all
>other RPC services which might get installed and be open to the world
>otherwise (i.e. SGI's fam if you are using GNOME).
>Just my 2c.
>[1] See


Anibal Monsalve Salazar
 .''`. Debian GNU/Linux
: :' : Free Operating System
`. `'  http://debian.org/
  `-   http://v7w.com/anibal

Attachment: signature.asc
Description: Digital signature

Reply to: