Re: avahi-daemon
Hi,
On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote:
> On Fri, 03 Mar 2006, Loïc Minier wrote:
> > If music sharing is a questionable feature to you, you don't need to
> > discuss this further, you're obviously the security guy, talking in
> > debian-security@ of stuff he doesn't want to support security-wise, and
> You are *not allowed* to support security holes by the Social Contract, on
> the grounds that they can cause far more damage to users than whatever
> benefits they might bring. So drop the attitude. We're trying for a
> middle-ground solution, here.
The Social Contract empowers me to serve our users. This is what I
believe I'm doing. What about *you* drop the attitude. *I'm* trying
for a middle-ground solution too, as long as it works by default. I
proposed multiple options in other posts, all of them ignored. People
*not* trying for a middle-ground solution are those claiming an open
port by default is unacceptable, no matter what.
> > don't want to see running on his server. Would this discussion happen
> > on a multimedia list, the situation would be kind of the opposite, and
> > people would be shouting loud if that wasn't pulled in by default.
> Then they can (read: should) use DeMudi, and DeMudi has all the excuses in
> the world to ship with all mdns services enabled by default. The Debian
> project *officially* recognizes the need for specialized distributions, you
> know.
Or perhaps people wanting total security should create their own distro.
Perhaps these people should use Euronode, Gibraltar, or Luinux.
> OTOH, when you package for Debian, you are doing the general distribution
> packaging. You are not allowed to cather to any special group needs in
> detriment of security, expect a lot of complaining if you do.
And when I package GNOME stuff for Debian, I'm doing general GNOME
packaging in Debian packages. I'm not allowed to cather to any special
group needs in favor pf security and in detriment of features.
Will you push me in reverting any argument you provide in favor of
security the other way around, or is my point sufficiently clear?
Please, bring solutions in this discussion, not arguments, we've got
enough already.
> So let's work on a way to reach a middle ground, shall we? In fact, I think
> you already stated in another post that a master switch would be fine, so
> this discursion could very well end here and now.
Yep, I proposed multiple solutions already, one of which being a
debconf-handled setting to start avahi on boot or not (which obviously
would need to be set to start by default, as for other daemons).
> The master switch addresses both your needs, and the security ones. All you
> need to do is not to hide it if you're shipping it with the default being
> the less secure choice.
I didn't intend to hide it, but it probably won't be high-priority, as
we both know how this clutters Debian installs.
> IMHO, make it priority medium, use a shared template that all mdns services
> can use (there is no reason why we shouldn't generalize this solution), and
> you can default to mdns enabled. Do not use priority low, unless you are
> going to default to mdns disabled.
I don't know between priority medium and low. I should probably look
at existing debconf-handled settings to get a picture.
> > Besides, the work is done quite cleanly with a chroot and a separate
> > user.
> Yes, which is good. But don't feel singled out, we are just as severe with
> every package. A lot of them decided to ship bound to localhost for this
> reason. Others implement master switches through debconf. Others prefer to
> ship with functionality disabled.
And here comes localhost again: it's the fourth time someone mentions
listening to localhost in this discussion, which is quite worthless for
a publishing / discovery daemon.
> As for using a separate user, that is the *rule*, not the exception. Yes,
> some crap in Debian still wants to run as root by default for dubious
> reasons, but that's not the rule anymore.
Still, samba will be more common than avahi for a while.
> Do not assume you can even *run* an active (as opposed to a passive -
> listens only, never transmits) mdns service in a network just because a
> package that has mdns capabilities was installed: you cannot know that.
That's not enough to have something active, the functionality must be
enabled in the music player too.
> > I completely agree with the managed network part, but in such a
> > network:
> > - would you have music players installed?
> > - wouldn't you filter out any other port than HTTP, HTTPS, and FTP?
> Inside the network? Most managed networks have filtering at the borders, at
> key router nodes, and if it has a more advanced distributed-firewall
> mentality, on the all of the important boxes themselves (but that usually
> doesn't reach the workstations).
I thought security people would recommend havin a per-port ACL for
allowed traffic, and port visibility set to limit the view to only the
router when not otherwise required.
I completely agree that it's quite common to have the network filtered
at its borders, and that's usually considered some internal trusted
network.
Anyway, I'm not the avahi maintainer, I'm quite sure he would be ok to
apply a patch providing the relevant debconf-handled settings, would he
get a bug report requesting this.
Cheers,
--
Loïc Minier <lool@dooz.org>
Current Earth status: NOT DESTROYED
Reply to: