> > 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
> > risk.
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.
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). 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.
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
fi
--------------------------------------------------------------------
This is going to be a big issue when upgrading from sarge -> etch since you
are _not_ managing the file at all!
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.
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.
Javier
[1] See
http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-rpc
Attachment:
signature.asc
Description: Digital signature