Re: avahi-daemon uses 100% of cpu when scanned with nmap (DoS possible?)
Package: avahi-daemon Version: 0.6.27-2 Tags: security Severity: critical Justification: Introduces possible denial-of-service scenario. Hi, when I scan my server from another machine on the network using nmap, I get this: [snip] It seems that mandriva already released an update for avahi : http://lists.grok.org.uk/pipermail/full-disclosure/2011-February/079525.html I guess you're facing the same issue. Regards -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/04cad33b021e7c91a76da3404fb76f3f.squir...@www.c0a8.org
Re: avahi-daemon uses 100% of cpu when scanned with nmap (DoS possible?)
On Thu, 2011-02-24 at 15:31 +, Julien Reveret wrote: [snip] It seems that mandriva already released an update for avahi : http://lists.grok.org.uk/pipermail/full-disclosure/2011-February/079525.html I guess you're facing the same issue. 0.6.28-4 has been accepted to unstable yesterday and afaik the fix was uploaded to stable-security but not yet accepted. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: avahi-daemon
On Fri, Mar 03, 2006, Joey Hess wrote: Standard Desktop task installs do not install Recommends anyway, so rhythmbox does not pull in avahi-daemon in those situations and you need to deal with that somehow. It's a but in task installation then. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote: On Fri, 03 Mar 2006, Loïc Minier wrote: On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote: True. But that requires a broken kernel, which we patch regularly as a security procedure anyway. Mounting removable filesystems suid,dev allow a lot more damage *by design* in the standard Linux security-model. And we also support avahi security-wise, and would patch it in the case of a knwon vulnerability. Nobody ever implied that avahi is badly maintained. And unless mdns/avahi is somehow being shipped configured in such a way so as to allow for immediate local root priviledge escalations, I don't think I understood the point you wanted to make. You were making the point that it's a security bug to mount USB sticks automatically without nodev and nosuid, and people responded to you that it was already a security risk to mount a filesystem automatically. You finally replied that implies a borken kernel and the kernel is supported security-wise. My point was to draw the following parallel: - mounting a filesystem automatically = listening on the network - kernel vulnerable = avahi vulnerable - kernel supported security-wise = avahi supported security-wise (- protecting with nodev nosuid = not having anything advertized) I stated that the fact that an hipotetic kernel bug *also* allows for local root exploits through a nosuid,nodev removable filesystem does *not* excuse us to have removable filesystems being mounted suid,dev, which depending on the filesystem type allows for immediate local root privilege escalation, *by* *design*. Which I completely agree with. But by default, no music is shared via avahi, so it would require a bug in avahi (exactly like it would require a bug in the kernel) to do anything nasty. Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Internal trusted networks? (was Re: avahi-daemon)
Hi, On Sat, Mar 04, 2006, Javier Fernández-Sanguino Peña wrote: 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 don't think you have seen many corporate (i.e. hundreds of nodes) networks. I've seen a few, and, from my limited experience: Uh, I never said that's what I would expect to see on a corporate networks. I've connected to networks at HP, I've connected to network of security firms, and they didn't have the measures I mentionned. I've read about using such drastic limitations in the interview of a famous security guy (and considered the idea was too impractical to applu to the networks I manage). It was someone famous, like some Netfilter or OpenBSD architect, but I can't find the article where I've read that (help welcome to find it back). So even if the security people as you so put it, would recommend per-port ACL allowed traffic they would (and do) get shunned by other IT departments. At most, IT security can get a bridge firewall [1] setup between sensible networks to isolate and try to control traffic between them. Right, _in practice_ no one can follow very strict security guidelines, which is the point I was making in mentionning extreme security measures. In practice, security has limits. With people bringing laptops (and all kind of devices) from the outside of the network, unprotected/uncontrolled WiFi access points, etc. there is no such thing as an internal trusted network. But you're still way more secure while sitting behind a NAT with responsible coworkers than connected to the Internet directly, without any firewall, and that's where desktops sit most of the time. Bye, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, Mar 03, 2006, Michael Stone wrote: On Fri, Mar 03, 2006 at 02:36:38PM +0100, Loïc Minier wrote: Do you have any other solution permitting the same functionalities, but without the listening port? No. If someone wants that functionality than that's how they need to get it. The question has always been about what level of effort is necessary on the user's part to enable that functionality. My point of view is that installing the application gets them the functionalities they'd expect to find in the default setup. But you are doing nice in pointing at typical services running on a desktop machine: - apache2 (and will be even more common with gnome-suer-share and DAV file sharing) - samba You think that's part of a typical desktop system? Fascinating. Yes, I think these are often part of a desktop. Does any of these run chrooted like avahi does? Samba even runs as root. Which of samba or avahi has the power to change file ownership, permissions, or simply to serve sensible files such as /etc/shadow? You continue with the specious arguments. What non-server dependency pulls in samba? What dependency pulls in gnome-user-share? The argument isn't whether someone who intentionally installs a package should get the functionality of the package, it's about what kind of side-effects might unknowningly be enabled by someone installing an apparantly unrelated package. If you find my last arguments were specious, let me reformulate them for your reading pleasure: straight: - I believe other apps typically installed on desktop systems are way more dangerous that the big hole people consider opened by avahi - avahi doesn't need a lot of rights to run, by design, and beyond this implements the classical security enhancements one expects to find in clean daemons In other words, even if it opens a new port, I believe this is less a security concern for desktops than other typical services. Concerning your dependencies remarks, I think I've answered to them enough already: this is a Recommends, nothing pulls in rhythmbox from a standard install up to a gnome-desktop-environment install, I proposed dependencies workarounds for most use cases (have a conflict from security packages, use your own meta-package...). Frankly, you're not considering the arguments I gave on dependencies, you even ignored them multiple times already, and since the core of this issue is about dependencies, and the fact that rhythmbox pulls in avahi by default, I'm not inclined to be interested in continuation of this discussion. If you feel there's a technical problem with the technical choices of a package or meta-package, bring it as a bug report, linking to this discussion, and if you don't get maintainer's agreement, please bring it to a technical committee. It's really here to help take technical decision where consensus can not be reached. -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, Mar 03, 2006, Javier Fernández-Sanguino Peña wrote: On Fri, Mar 03, 2006 at 02:36:38PM +0100, Loïc Minier wrote: This is a desktop machine, it should permit sharing of files on your local network. DNS servers have their port 53 open to respond to name resolution queries, just consider your desktop installation to be a name server responding to stuff such as what services are available, what shares are available etc. /me looks doumbfounded Excuse me? Since when does a typical desktop machine provide users to share *music* on a local network? (Don't tergiverse the fact that ahdavi is used, in rythmbox, to share music, not files) I said sharing of files, and I meant files only, as in sharing of data files between coworkers with samba for example. And for the same thing, why would a typical desktop machine provide users to share even files! My desktop system at home (and my parent's and my uncle's and whatnot) are completely stand-alone desktop systems, connected to the Internet, with no LAN. They only need to talk to their (serial or USB connected) printer, that's all! Fine, and perhaps you don't even need music sharing on them, but does it still automounts filesystems plugged in USB? :) One can't know in advance what uses a system is for, I believe people installing Rhythmbox want to be able to share music by default (easily). You're free to believe the contrary, it's a matter of opinion, I gave numerous arguments to my position already, and don't want to talk in loops any further. You don't want it? Don't install it or configure it the way you like. I'm surprised that the over-bloat of Windows' desktop is now considered to be the good way of doing things. I'd rather have drawn a parallel with Apple software, such as MacOSX, or their Wifi APs. Please have a look at their traffic and open ports next time you get near one of them. Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
Hi, On Sat, 2006-03-04 at 10:26 +0100, Loïc Minier wrote: Concerning your dependencies remarks, I think I've answered to them enough already: this is a Recommends, nothing pulls in rhythmbox from a standard install up to a gnome-desktop-environment install, I proposed dependencies workarounds for most use cases (have a conflict from security packages, use your own meta-package...). Well, since the gnome meta-package is part of the gnome task, which I consider a common default to setup a desktop machine, it get's pulled in in an environment where Recommends are installed automatically. I think, your proposed solutions do not cover this issue at all. Users, who know what they want and what they are doing, do not run into this problem, since they can manually deselect avahi-daemon. We are indeed talking about regular users. In another mail, you agreed, the maybe only 10% of them want to share music. So, why give another open port to the other 80% (assuming, that 10% of the users know what they are doing ;o)). If you feel there's a technical problem with the technical choices of a package or meta-package, bring it as a bug report, linking to this discussion, and if you don't get maintainer's agreement, please bring it to a technical committee. It's really here to help take technical decision where consensus can not be reached. I have a technical question here. First of all, I think, that avahi-daemon listening on all interfaces by default, is what we want. It's the only reasonable setup for a multi-cast discovery daemon. A Debconf question about this is not even necessary here, IMHO. OTOH, the majority of Rhythmbox users might not want to share music, but install rhythmbox in an environment, where Recommends are pulled in automatically. Ok, we discussed that. But still it's only a Recommends. Therefore, rhythmbox needs to handle the absence og avahi-daemon gracefully, since you cannot rely on it's installation. For sake of plug-and-play and comfort, this might be even done in some kind of GUI message, which tells the user what to do, if he/she wants to access a feature, that requires the daemon's presence. If you agree on this, there is no reason, to lower the dependency to a Suggests and everybody would be happy. If you still think, that a feature, that is present by default but might be used only by a limited number of users overweighs the possible security implications of another open port, I think we really cannot come to a consensus in this point. My two cents. Philipp signature.asc Description: This is a digitally signed message part
Re: avahi-daemon
On Fri, Mar 03, 2006, Javier Fernández-Sanguino Peña wrote: (IMHO this dicussion is reaching to a point in which it should move to d-devel instead, but I'll keep it here) Uh, please don't move it there, in the contrary, this discussion already reached flame-level, and no arguments are coming in. I'd rather get things settled down, and solutions implemented. I made some efforst in listing solutions here, and in the bug report MS opened. I don't want the burden of following a new flame in debian-devel@ . It would be overly complicated to handle the case of a Suggests instead of a Recommends correctly: even if the code was updated to handle both Overly complicated? You are overestimating it. It's as simple with a Suggests: as with a Recommends: (people still use 'apt-get' which does not pull in Recommends: automatically). The software cannot rely on it being installed so it should check if the thing it needs is there, if it's not then it asks the user to install it. You've cut what I said, I explained why I didn't like that. Please don't cut like that, that's quoting out of context. I said it woud require code to disable preferences when avahi isn't there, the documentation would still refer to the features, but the user wouldn't have them, and a dialog would be ugliest: it would introduce package level information within an application. Yes, some of this can be done (patch for the runtime part welcome, file it, I'll check it, send it upstream, apply it). This can be an error in STDERR (as it is now, I believe) but, more elegantly, could be a window message instructing users what to do and what they gain (and lose) if they do (or don't). It's not that complicated. Please, send a patch. The code assumes it's there right now (and would crash if it wasn't in the past, hence the previous Depends dependency), feel free to enhance it to support a missing avahi at runtime nicely. So? The whole point of documentation is to tell people how to do stuff. Rhythmbox' section on Share music should start with You need to have installed for this feature to work. That's it. As simple as that. What a nice integration level, while you're at it, mention the ./configure switches. We're talking desktop users here, that is works out of the box. Based on that, you could assume that having more than one computer per household is not all that common. So, I *believe* that your average computer home user is typically going to extract music from CDs (to listen in their computer or on other devices, like MP3 players) more, on average, than sharing with neighbour PCs. You can stop right here, I'm not arguing it's useful on all computers, or even on the average computers. Besides, we're only considering computers where rhythmbox is installed. Now, take a look at Grip (install it), it's an application to extract audio data from CDs. Grip is useless unless you install additional encoders. If you don't have them (and there are in it's Suggests: or Depends:) then the software should instruct you to go and install them. Grip fails to do so properly, and people bug it often. There's no MP3 encoder in the Debian archive, what should Grip do then? This is mixing the MP3 encoder problem with a completely unrelated one. Please install sound-juicer, it will encode Ogg vorbis just fine, and by default. Do you see still think that the argument for the sake of Plug Play, for the sake of the average user should brandished in front of people as an excuse for not doing things properly? You're mixing issues. The fact stuff is patent encumbered and can't enter Debian has nothing to do with the current discussion. It would certainly be nice if we could legally permit people to install MP3 encoders, like MacOSX does. You might as well get the issue documented in the RB BTS if you want, I'll simply link to this thread where I clearly state that I think it's a desirable feature which should be working by default. :) I don't agree with you here and if I get to see avahi being installed in a default GNOME install in Debian and will make damn sure that I get to see it removed. Please do follow your opinions, I have no problem with that. I took the decision of the current deps with my own judgment, and hold to it after what I've read or heard on the subject. I wouldn't oppose any superior ruling to my judgment, which might be technically incorrect. The dep was strict because RB wouldn't start without it. Now it will start, but with a warning. I'm quite sure you can get it to crash if avahi isn't there though, but that's a bug. Then it's a bug, and it should be fixed in RB. Feel free to report it, and to provide a patch. It doesn't change the fact that the Recommends is there for functional reasons. That functionality is not required for most desktop users. Period. For every user you can show up that requires that I can show you
Re: avahi-daemon
On Sat, Mar 04, 2006 at 10:31:02AM +0100, Loïc Minier wrote: And for the same thing, why would a typical desktop machine provide users to share even files! My desktop system at home (and my parent's and my uncle's and whatnot) are completely stand-alone desktop systems, connected to the Internet, with no LAN. They only need to talk to their (serial or USB connected) printer, that's all! Fine, and perhaps you don't even need music sharing on them, but does it still automounts filesystems plugged in USB? :) It's not the same case, not at all. USB filemounts require local access to the system, connecting to a remote daemon does not. There's no paralellism here even if you want to force it. One can't know in advance what uses a system is for, I believe people installing Rhythmbox want to be able to share music by default (easily). You're free to believe the contrary, it's a matter of The truth is that people don't get rhythmbox because they installed it explicitly, they get rhythmbox because they installed 'gnome'. It's just not the same thing. And also: Rhythmbox is a very easy to use music playing and management program which supports a wide range of audio formats (including mp3 and ogg). The current version also supports Internet Radio, iPod integration, Audio CD burning, and metadata editing. There's *nothing* in that description (which is Rhythmbox' package) that implies that Rhythmbox provides music sharing capabilities. Is there? opinion, I gave numerous arguments to my position already, and don't want to talk in loops any further. You don't want it? Don't install it or configure it the way you like. It's not that I don't want it (I don't) I don't want a GNOME install to have it. I don't want user *users* to have a music sharing application they will certainly not need. I'm surprised that the over-bloat of Windows' desktop is now considered to be the good way of doing things. I'd rather have drawn a parallel with Apple software, such as MacOSX, or their Wifi APs. Please have a look at their traffic and open ports next time you get near one of them. Hah! That made me laugh for a bit. Please take a look at MacOS X security record, and their plug and play simplicity. For further reference I suggest you read: http://isc.sans.org/diary.php?storyid=1138 In its default configuration shell commands are executed simply by visting a web site - no user interaction required. http://www.securityfocus.com/brief/152 and http://docs.info.apple.com/article.html?artnum=303382 (take a look at the 'automount' and 'Safari' issues) Yes, plug and play is all fine and dandy, but if you take it to the extreme you get bitten by these bugs. I wouldn't be surprised if people taking the same route (hundreds of developers yelling plug play! plug play!) led the systems they developed to the same consequences (remote exploitable bugs and worms). Regards Javier signature.asc Description: Digital signature
Re: avahi-daemon
On Sat, Mar 04, 2006 at 09:51:31AM +0100, Loïc Minier wrote: On Fri, Mar 03, 2006, Joey Hess wrote: Standard Desktop task installs do not install Recommends anyway, so rhythmbox does not pull in avahi-daemon in those situations and you need to deal with that somehow. It's a but in task installation then. It's not a bug. I'm pretty damn sure that Joey knows what he's doing there. Javier signature.asc Description: Digital signature
Re: avahi-daemon
Hi, On Sat, Mar 04, 2006, Philipp A. Hartmann wrote: Well, since the gnome meta-package is part of the gnome task, which I consider a common default to setup a desktop machine, it get's pulled in in an environment where Recommends are installed automatically. Yup, so the GNOME task pulls it in by default, which means you get the feature and the open port. I think, your proposed solutions do not cover this issue at all. Users, who know what they want and what they are doing, do not run into this problem, since they can manually deselect avahi-daemon. We are indeed talking about regular users. In another mail, you agreed, the maybe only 10% of them want to share music. So, why give another open port to the other 80% (assuming, that 10% of the users know what they are doing ;o)). Ah you're correct, let's make it a Recommends: for the 10% of people wanting to share music, and a Suggests: for the 80% of people having no clue and which will never share music in the life of their system. But still it's only a Recommends. Therefore, rhythmbox needs to handle the absence og avahi-daemon gracefully, since you cannot rely on it's installation. For sake of plug-and-play and comfort, this might be even done in some kind of GUI message, which tells the user what to do, if he/she wants to access a feature, that requires the daemon's presence. It's completely correct to request the proper behavior of RB when the recommends isn't there. I could be very silly, and argue the other way around with something like the current RB code doesn't properly permit using RB without avahi-daemon intalled, and make that a Depend, but since I knew it was causing pain to people wanting a system without avahi but with gnome, and since RB was fixed not to crash when avahi wasn't there, I could downgrade that to Recommends. In other words, RB could be enhanced to work better when the Recommends isn't installed indeed. I don't consider a popup in the application to request installation of packages sensible at all. If you agree on this, there is no reason, to lower the dependency to a Suggests and everybody would be happy. If you still think, that a feature, that is present by default but might be used only by a limited number of users overweighs the possible security implications of another open port, I think we really cannot come to a consensus in this point. It's exactly the way you put, it, we can not come close to a consensus by comparing apples to oranges, security and usability. I must add people on this list are obviously biased towards security. Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Sat, Mar 04, 2006 at 11:07:25AM +0100, Loïc Minier wrote: I'm doing my final pass on the deb-sec part of this discussion, I don't intend to participate much further, no new arguments are popping up. Quite sincerily, this discussion is getting nowhere. There are sufficient arguments in this discussion to drive a truck through a wall, you just don't want to heed them. Some facts: - rhythmbox does not mention music sharing *at*all* in the package description. Even the GUI doesn't mention this (when starting it up for the first time) nor the documentation (in it's 'Introduction') - rhythmbox does not work properly if the discovery service (provided by ahavi-daemon) is not installed [1] - music sharing on the same LAN is not something most desktop users want to do (most households in European countries have a single PC per household) - (history shows...) network services, even if properly designed, are open to exploitation (the all software has bugs corollary) So, IMHO: - a default GNOME install should *not* install a network service, even if that enabled new features to the users. Consequently, if rhythmbox is part of the GNOME task, it should not pull in ahavi-daemon automatically (a Recommends: is automatic for aptitude, not for apt-get, and aptitude is the tool we suggest in our Release Notes for upgrades) - if rhythmbox has to be a part of the GNOME task, it should lower the ahavi-daemon dependency to a Suggests: - rhythmbox should be fixed, if it doesn't work without ahavi-daemon, to popup a window when you try to share music [2] and tell the user what steps it needs to take to enable that I'm CC'ing this to the bug report and open bugs to rhythmbox accordingly. Regards Javier [1] Or so does Loïc Minier say, whileas, I've found that I only see this when starting it up and all the features work just fine for me: (rhythmbox:25826): Rhythmbox-WARNING **: Unable to start mDNS browsing [2] It currently just says this when you set this on the Preferences: (rhythmbox:25826): Rhythmbox-WARNING **: Unable to notify network of music sharing signature.asc Description: Digital signature
Re: avahi-daemon
On Sat, Mar 04, 2006, Javier Fernández-Sanguino Peña wrote: Rhythmbox is a very easy to use music playing and management program which supports a wide range of audio formats (including mp3 and ogg). The current version also supports Internet Radio, iPod integration, Audio CD burning, and metadata editing. There's *nothing* in that description (which is Rhythmbox' package) that implies that Rhythmbox provides music sharing capabilities. Is there? Of course, you didn't imagine for a second that the description wasn't updated since the introduction of avahi. -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Sat, Mar 04, 2006 at 10:26:31AM +0100, Loïc Minier wrote: My point of view is that installing the application gets them the functionalities they'd expect to find in the default setup. And I agreed that perhaps the rhythmbox community would expect that, which is why I reconsidered and asked for its removal from the gnome task. But you were already pissed off and didn't even seem to give any consideration to the question of whether the rhythmbox community and the gnome community are the same. But you are doing nice in pointing at typical services running on a desktop machine: - apache2 (and will be even more common with gnome-suer-share and DAV file sharing) - samba You think that's part of a typical desktop system? Fascinating. Yes, I think these are often part of a desktop. Often is not the same as should always be installed by default on a common configuration, even if I agreed with the often categorization. If you find my last arguments were specious, let me reformulate them for your reading pleasure: straight: - I believe other apps typically installed on desktop systems are way more dangerous that the big hole people consider opened by avahi *none* of the services you listed are installed by a task that a user would typically select for a desktop system. A person who wants those things has to select them specifically. You have yet to acknowledge that. Concerning your dependencies remarks, I think I've answered to them enough already: this is a Recommends, nothing pulls in rhythmbox from a standard install up to a gnome-desktop-environment install, I proposed dependencies workarounds for most use cases (have a conflict from security packages, use your own meta-package...). You haven't really answered them, you've basically just decided that every gnome user should be a music sharer, and if they don't want it they should go out of their way to avoid it. IOW, instead of a simple, common procedure to install that functionality, you advocate an obscure, complicated one to disable it. Frankly, you're not considering the arguments I gave on dependencies, you even ignored them multiple times already, and since the core of this issue is about dependencies, and the fact that rhythmbox pulls in avahi by default, I'm not inclined to be interested in continuation of this discussion. Umm, I did consider it--that's why I stopped arguing about the rhythmbox dependency. If you feel there's a technical problem with the technical choices of a package or meta-package, bring it as a bug report, linking to this discussion, and if you don't get maintainer's agreement, please bring it to a technical committee. It's really here to help take technical decision where consensus can not be reached. I feel the technical committee is useless in its current form, so I will not be doing so. If someone else wants to, that's fine. I had hoped to simply arrive at some common ground, but you seem to feel that's impossible at this point. -- Michael Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Sat, Mar 04, 2006 at 11:16:08AM +0100, Loïc Minier wrote: I must add people on this list are obviously biased towards security. I guess you can stake out the ground of biased against security, but that's kind of a bad place to be for a software distributor in the 21st century. -- Michael Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
Loïc Minier wrote: On Fri, Mar 03, 2006, Joey Hess wrote: Standard Desktop task installs do not install Recommends anyway, so rhythmbox does not pull in avahi-daemon in those situations and you need to deal with that somehow. It's a but in task installation then. If you mean a bug, no, I go out of my way to not install recommends, because Debian is still rife with long and useless recommends chains. -- see shy jo signature.asc Description: Digital signature
Re: avahi-daemon
Philipp A. Hartmann wrote: But still it's only a Recommends. Therefore, rhythmbox needs to handle the absence og avahi-daemon gracefully, since you cannot rely on it's installation. For sake of plug-and-play and comfort, this might be even done in some kind of GUI message, which tells the user what to do, if he/she wants to access a feature, that requires the daemon's presence. If avahi is not running, rhythmbox prints this to std(something) on startup and/or when you enble sharing in its prefs: (rhythmbox:24998): Rhythmbox-WARNING **: Unable to start mDNS browsing (rhythmbox:24998): Rhythmbox-WARNING **: Unable to notify network of music sharing Otherwise it behaves fine. -- see shy jo signature.asc Description: Digital signature
Re: avahi-daemon
Javier Fernández-Sanguino Peña wrote: - rhythmbox does not mention music sharing *at*all* in the package description. Even the GUI doesn't mention this (when starting it up for the first time) nor the documentation (in it's 'Introduction') Rhythmbox doesn't go broadcasting files over the network without being explcitly told to do so in the prefs. It does do mdns discovery of other music shares on the network automatically though. - a default GNOME install should *not* install a network service, even if that enabled new features to the users. Consequently, if rhythmbox is part of the GNOME task, it should not pull in ahavi-daemon automatically (a Recommends: is automatic for aptitude, not for apt-get, and aptitude is the tool we suggest in our Release Notes for upgrades) Does aptitude actually pull in new recommends when upgrading a package? IIRC it did not. -- see shy jo signature.asc Description: Digital signature
Re: avahi-daemon
On Sat, Mar 04, 2006, Joey Hess wrote: If you mean a bug, no, I go out of my way to not install recommends, because Debian is still rife with long and useless recommends chains. I completely agree there are a number of broken recommends, but shouldn't we fix these? Yes, it's painful. :( -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
Loïc Minier wrote: I completely agree there are a number of broken recommends, but shouldn't we fix these? Yes, it's painful. :( I'd prefer not to break new installations in order to find them. This thread shows that pulling in recommends by default in aptitude is enough to expose problimatic recommends chains eventually. -- see shy jo signature.asc Description: Digital signature
Re: avahi-daemon
On Sat, Mar 04, 2006 at 01:26:24PM -0500, Joey Hess wrote: If avahi is not running, rhythmbox prints this to std(something) on startup and/or when you enble sharing in its prefs: Notice that *most* users will not see this as they will start up rhythmbox from a GNOME application menu and not their terminal. (rhythmbox:24998): Rhythmbox-WARNING **: Unable to start mDNS browsing (rhythmbox:24998): Rhythmbox-WARNING **: Unable to notify network of music sharing Otherwise it behaves fine. Yes it works. But check out '#355238: rhythmbox: A user cannot see why he cannot share music', there's something interesting in my bug report. The funny thing is that, even if the maintainer claims that this is a requierement, something that most people will want to use and blah blah: a) is not properly documented (see bug #355234), not even in the application documentation! b) it comfounds users, since a user that *does* wants to share music will enable it, the GUI marks it at enabled and does *not* work So much for plug and play and user friendliness, huh? Javier signature.asc Description: Digital signature
Re: avahi-daemon
On Sat, Mar 04, 2006 at 11:32:20AM +0100, Loïc Minier wrote: On Sat, Mar 04, 2006, Javier Fernández-Sanguino Peña wrote: Rhythmbox is a very easy to use music playing and management program which supports a wide range of audio formats (including mp3 and ogg). The current version also supports Internet Radio, iPod integration, Audio CD burning, and metadata editing. There's *nothing* in that description (which is Rhythmbox' package) that implies that Rhythmbox provides music sharing capabilities. Is there? Of course, you didn't imagine for a second that the description wasn't updated since the introduction of avahi. Which I'm surprised, since the introduction of avahi was a fundamental change. Moreover, there is not a slightest note in the (upstream) documentation or the README.Debian about music sharing and avahi. (for those that are not the maintainer, see #355234) I'm *very* surprised that this kind of change, which you tout as fundamental for the package and which, at some point, prevented the program from working at all is not documented anywhere in the package or upstream. Regards Javier signature.asc Description: Digital signature
Re: avahi-daemon
On Sat, Mar 04, 2006 at 01:41:14PM -0500, Joey Hess wrote: - a default GNOME install should *not* install a network service, even if that enabled new features to the users. Consequently, if rhythmbox is part of the GNOME task, it should not pull in ahavi-daemon automatically (a Recommends: is automatic for aptitude, not for apt-get, and aptitude is the tool we suggest in our Release Notes for upgrades) Does aptitude actually pull in new recommends when upgrading a package? IIRC it did not. Well, since rhythmbox is part of the gnome task, and it was already included in the gnome meta-package in sarge I guess you are correct (now). However, for sid users, notice that rhythmbox depended on avahi-daemon from version 0.9.2-3 (2006-01-22) until version 0.9.3-1 (2006-02-05). So, any sid user that upgraded his system (even from sarge or etch) in those two weeks (from January the 22nd to February the 5th) they *will* have avahi installed regardless. Also, any user that does a limite install and then installs the gnome meta-package (not the gnome-desktop task with tasksel) will pull in avahi too. Regards Javier signature.asc Description: Digital signature
Re: Internal trusted networks? (was Re: avahi-daemon)
On Sat, Mar 04, 2006 at 10:12:56AM +0100, Loïc Minier wrote: But you're still way more secure while sitting behind a NAT with responsible coworkers than connected to the Internet directly, without any firewall, and that's where desktops sit most of the time. Well, a NATed gateway is not that common for some desktop systems: - home users using bridge Internet connections (some cable companies provide cable-modem that act as a bridge) - dialup users (yes, there are still those kind of users) Regards Javier signature.asc Description: Digital signature
Re: avahi-daemon
Hello, Maintainers remember: it's much better to *not* install/activate a network service than to have a service, even if it's chrooted, or running under lower privileges (like the ahavi maintainers describe in https://wiki.ubuntu.com/MainInclusionReportAvahi) which, BTW, is not that common. The keyword here is 'exposure'. The avahi-daemon is nicely chrooted, and runs under a different user. You just can't have the functionality of plug'n'play on a network without any central server without listening at some point to something... Can you please count the open ports on your system? Are there still telnet, timeserver, sunrpc ... waiting for connections? Why did you disable them? I am sure this was discussed several times in the past. Anyway, it is an open secret to better not connect your new installed debian to internet until you have switched down all these security-riscs (Btw. with new installed windows XP you should better not connect to the internet without activating a firewall first and updating your system because otherwise you will get infected with some worm within minutes... - I am sure Windows Vista will disable all listening services until the user turns them on or at least activate a firewall by default for internet access). I am sure most debian users and admins will say something like But this is debian..., Admin is responsible for security... or root must know what he is doing I think this is a general security problem here. You are right, plug'n'play is cool thing the normal user want. But I also asume that this normal user wont be aware of this listening port, don't you think so? Please count the open ports on your systems again... how many are there? Maybe samba, even maybe ssh and apache and maybe this avahi (that is not as known as the rest). I think it is justified to ask the user/admin to activate this avahi thing... I don't think the user's will get spamed with these kind of questions even if we would have this as a general rule. People can have the avahi-feature anyway and I think asking *one* time a security related question would be a good thing. In addition to that unexperienced users will learn the general rule that an open port is a security risk! Really, do *almost all* rhythmbox users need to share music (and consequentely need ahavi)? That's not the point, the point is to make it easy to do so. And yes, a lot of users share music between computers. Those people want that to be simple. You can't cut every feature out because only 10% of the users use it. It's not like you're running Rhythmbox on a firewall, and iptables is still there, you can remove avahi, you can configure it not to start etc. Better let a user explicitly activate it if he needs it. That application can suggest him to do so if the rhytmbox-power-user will press the button browse for music... regards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
Hi, On Fri, Mar 03, 2006, aliban wrote: Can you please count the open ports on your system? Are there still telnet, timeserver, sunrpc ... waiting for connections? On my system? nmap reports: 53/tcp open domain Some netstat digging shows: tcp0 0 0.0.0.0:53 0.0.0.0:* LISTEN 18007/pdnsd udp0 0 0.0.0.0:53530.0.0.0:* 29989/avahi-daemon And so what? Do you want to proove me it listens on the network? That's by design, the point is to listen for queries. Why did you disable them? I didn't disable anything, I installed what I wanted. I installed iptables and have set it up too. I am sure this was discussed several times in the past. Anyway, it is an open secret to better not connect your new installed debian to internet until you have switched down all these security-riscs (Btw. with new installed windows XP you should better not connect to the internet without activating a firewall first and updating your system because otherwise you will get infected with some worm within minutes... - I am sure Windows Vista will disable all listening services until the user turns them on or at least activate a firewall by default for internet access). I am sure most debian users and admins will say something like But this is debian..., Admin is responsible for security... or root must know what he is doing This is a desktop machine, it should permit sharing of files on your local network. DNS servers have their port 53 open to respond to name resolution queries, just consider your desktop installation to be a name server responding to stuff such as what services are available, what shares are available etc. I think this is a general security problem here. You are right, plug'n'play is cool thing the normal user want. But I also asume that this normal user wont be aware of this listening port, don't you think so? Do you have any other solution permitting the same functionalities, but without the listening port? I'm listening to any suggestions. BTW, this is a standard, that other software is adhering, such as Apple's iTunes. Will your solution permit interoperability with iTunes? Please count the open ports on your systems again... how many are there? Maybe samba, even maybe ssh and apache and maybe this avahi (that is not as known as the rest). I think it is justified to ask the user/admin to activate this avahi thing... I don't think the user's will get spamed with these kind of questions even if we would have this as a general rule. Sure, I'm fine with a debconf question permitting for example *not* to start avahi. It's just that this question will only be visible for certain priorities (for example only for priority = low, or medium), and will default to enable avahi (as for other daemons, and so that it works out of the box). But you are doing nice in pointing at typical services running on a desktop machine: - apache2 (and will be even more common with gnome-suer-share and DAV file sharing) - samba Does any of these run chrooted like avahi does? Samba even runs as root. Which of samba or avahi has the power to change file ownership, permissions, or simply to serve sensible files such as /etc/shadow? People can have the avahi-feature anyway and I think asking *one* time a security related question would be a good thing. In addition to that unexperienced users will learn the general rule that an open port is a security risk! Sure, no problem. Better let a user explicitly activate it if he needs it. That application can suggest him to do so if the rhytmbox-power-user will press the button browse for music... Well, no: that's the opposite of plug'n'play. See, if you're USB stick contains a malicious vfat file system, it gets automatically mounted nevertheless. It's a feature. Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
(This reply was started some days ago, but I thought it might be best to wait a little before responding to you. Besides, I took some time to document myself on some of the issues you mentionned.) Hi, On Wed, Feb 22, 2006, Michael Stone wrote: (nss-mdns does mdns too, but it's not related to avahi) Package: avahi-daemon Recommends: libnss-mdns The dependency chains here get a little scary. Indeed, but it's even worse! avahi-daemon recommends libnss-mdns which recommends zeroconf. However, both Recommends are bogus. There's a bug against the second one, and I talked a little with Sjoerd on the first one, and it seems it's not required either, it's more of something until we get a mdns task. So yes, you're correct, this is a scary dependency, which shouldn't be there. Nor the libnss-mdns dependency on zeroconf shouldn't be there (it should be the other way around actually). And zeroconf is a software which is known to cause some trouble in existing network configurations (not avahi alone). From a security point of view, everything feature introduce risk. If you base all you reasonning on security, that is if you make security rule number 1, you get zero feature. And if you introduce questionable features with huge security implications without thinking them through you get a real mess which is going to take a lot of work down the road to clean up. There's a real danger inherent in focusing on a particular bit of functionality and ignoring its larger implications, *especially* in a project as large as debian. 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 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. The rest of your point is simply too fuzzy to discuss any further, you're being too general sorry. You can't take the decision to remove a feature because most people install GNOME for other reasons than that feature. Otherwise one would use the same reasonning for all features in GNOME and remove them all. Your logic is frankly questionable. Anytime you start with a proposition like making that decision equates to removing every possible feature you're probably making a logical leap. Probably, I certainly don't have to discuss all features as painfully as this one. But there's no other way to get it, the point being in not having any central server, you have to listen for requests. Any other proposal to implement the functionality and interoperability with iTunes is welcome. Besides, the work is done quite cleanly with a chroot and a separate user. But sure, a small door has been opened which wasn't there before. I don't see any of those appearing on any network I maintain. I've now trumped your assertion with one of my own, do I win something? That's outrageous, the fact you don't have anything on your network is a real pity, it means you simply have no ground to talk on the feature you want absolutely removed. I've seen a lot of types of shares while browsing various networks, the latest of which were the networks of geeks at FOSDEM: typically a mixture of feature-maniacs, and security-paranoiacs. Surprisingly, lot's of stuff was advertized there, ranging from music and file shares to SSH, HTTP, or SFTP servers. Will other people at FOSDEM confirm this? Just install the service-discovery-applet and switch networks for a while. On any *managed* network I don't think that having stuff like this appear out of nowhere is particularly beneficial. On a small home network I'm not convinced it buys you anything because you're not generally dealing with enough stuff to need a service location solution. I'm sure its potentially very useful on geeky home networks with lots of systems and services, but I'm not sure that's a reasonable basis for a default configuration. Right, people running Debian or Ubuntu at home are typically not interested in sharing music between computers at home. 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? Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
Hi there, For people on the list interested in the discussion, Michael Stone has filed #355064, where the discussion went on. Bye, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, 03 Mar 2006, Loïc Minier wrote: This is a desktop machine, it should permit sharing of files on your local network. DNS servers have their port 53 open to respond to name In what planet do you live? Desktop machines are plugged to extremely hostile networks all the time (think cable modems). There is no *should* here, at all. Well, no: that's the opposite of plug'n'play. See, if you're USB stick contains a malicious vfat file system, it gets automatically mounted nevertheless. It's a feature. Not in my servers, it doesn't. And I should add, not even in my desktops: all removable filesystems are mounted nodev, nosuid. Mounting malicious filesystems automatically (vfat can't be one AFAIK, but it won't bork if you tell it to be nosuid, nodev either) is never a feature, it is a security hole. Actually, should we not file security bugs against everything that comes configured to mount removable filesystems out-of-the box and does so without specifying nodev, nosuid ? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, Mar 03, 2006 at 02:36:38PM +0100, Loïc Minier wrote: Do you have any other solution permitting the same functionalities, but without the listening port? No. If someone wants that functionality than that's how they need to get it. The question has always been about what level of effort is necessary on the user's part to enable that functionality. But you are doing nice in pointing at typical services running on a desktop machine: - apache2 (and will be even more common with gnome-suer-share and DAV file sharing) - samba You think that's part of a typical desktop system? Fascinating. Does any of these run chrooted like avahi does? Samba even runs as root. Which of samba or avahi has the power to change file ownership, permissions, or simply to serve sensible files such as /etc/shadow? You continue with the specious arguments. What non-server dependency pulls in samba? What dependency pulls in gnome-user-share? The argument isn't whether someone who intentionally installs a package should get the functionality of the package, it's about what kind of side-effects might unknowningly be enabled by someone installing an apparantly unrelated package. -- Michael Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, Mar 03, 2006 at 02:45:28PM +0100, Loïc Minier wrote: Indeed, but it's even worse! avahi-daemon recommends libnss-mdns which recommends zeroconf. However, both Recommends are bogus. There's a bug against the second one, and I talked a little with Sjoerd on the first one, and it seems it's not required either, it's more of something until we get a mdns task. So yes, you're correct, this is a scary dependency, which shouldn't be there. Ok, that sounds much better. 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 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. Well, that's why I reconsidered requesting changes to rhythmbox and suggested its removal from the generic gnome dependency instead. If the dependency chain was initiated by something a lot more specific than gnome (for example, music sharing or something) I'd feel a lot more comfortable with it. The problem here is that music playing is bluring into music serving, and IMO the communities interested in each don't necessarily overlap. I've never questioned whether there are people who want to share music, only how much functionality in that direction should be provided without a more explicit sign of interest from the user. The rest of your point is simply too fuzzy to discuss any further, you're being too general sorry. Well, it's a general problem. Every network service you enable has some risk. Some functionality requires network services. The decision about what services should be enabled on a fairly common out-of-the-box configuration should be made at the big-picture level, not at the level of a developer trying to maximize the functionality of a particular package. Unfortunately debian doesn't much concept of a steering committee. That's outrageous, the fact you don't have anything on your network is a real pity, Whoa, I didn't say I didn't have services on my network, I said that I don't have magical self-initiating services. If I want to provide something I make a decision to do so and give it a sensible/appropriate name service entry. I don't want my appliances or workstations deciding for themselves whether they should be services. As a matter of fact I have a music server on my (home) network--one that I specifically configured and enabled, and which isn't a workstation. I completely agree with the managed network part, but in such a network: - would you have music players installed? Why not? I find listening to some music at my desk to be nice. That gets back to the now-blurred line between music *player* and music *sharer*. - wouldn't you filter out any other port than HTTP, HTTPS, and FTP? I don't get that question. -- Michael Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, Mar 03, 2006 at 10:47:56AM -0300, Henrique de Moraes Holschuh wrote: Not in my servers, it doesn't. And I should add, not even in my desktops: all removable filesystems are mounted nodev, nosuid. Mounting malicious filesystems automatically (vfat can't be one AFAIK, but it won't bork if you tell it to be nosuid, nodev either) is never a feature, it is a security hole. Well, a filesystem can be malicious whether it's mounted nosuid or not. Consider the case of a crafted directory structure that tickles a kernel bug, for example. There's no question that making things easier for desktop users adds risks, the question is where to strike the balence. -- Michael Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, 03 Mar 2006, Michael Stone wrote: On Fri, Mar 03, 2006 at 10:47:56AM -0300, Henrique de Moraes Holschuh wrote: Mounting malicious filesystems automatically (vfat can't be one AFAIK, but it won't bork if you tell it to be nosuid, nodev either) is never a feature, it is a security hole. Well, a filesystem can be malicious whether it's mounted nosuid or not. Consider the case of a crafted directory structure that tickles a kernel bug, for example. There's no question that making things easier for True. But that requires a broken kernel, which we patch regularly as a security procedure anyway. Mounting removable filesystems suid,dev allow a lot more damage *by design* in the standard Linux security-model. So, I repeat my question: should we hunt down and file bugs (grave or worse) on packages automounting removable media without nosid, nodev ? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
automounting (was Re: avahi-daemon)
On Fri, Mar 03, 2006 at 11:20:56AM -0300, Henrique de Moraes Holschuh wrote: So, I repeat my question: should we hunt down and file bugs (grave or worse) on packages automounting removable media without nosid, nodev ? Here's what I'd suggest: Write a policy that covers best practices and see how current implementations map to it. Enter a dialog with maintainers of packages which do something else. See if you can get consensus. Address any concerns. At that point you can try to get the policy formalized. The problem is scoped tightly enough that it doesn't appear intractable. -- Michael Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
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. 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. 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. 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. not having any central server, you have to listen for requests. Any other proposal to implement the functionality and interoperability with iTunes is welcome. 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. 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. 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. 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. That's outrageous, the fact you don't have anything on your network is No, it is not. Your assumptions are just that, assumptions. And they may not be right. 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. Above all, never ever assume desktops are plugged to trusted networks. That is, in fact, outrageous. 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). Sure, there are places where the local workstations have remote-controlled firewalls, but they're not common (and AFAIK rarely used for anything but emergency virus/worm spread control). That said, music players are quite often allowed in a lot of managed networks. I never worked at a place where they were forbidden, in fact (but that doesn't mean music *sharing* is allowed). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, Mar 03, 2006 at 02:36:38PM +0100, Loïc Minier wrote: This is a desktop machine, it should permit sharing of files on your local network. DNS servers have their port 53 open to respond to name resolution queries, just consider your desktop installation to be a name server responding to stuff such as what services are available, what shares are available etc. /me looks doumbfounded Excuse me? Since when does a typical desktop machine provide users to share *music* on a local network? (Don't tergiverse the fact that ahdavi is used, in rythmbox, to share music, not files) And for the same thing, why would a typical desktop machine provide users to share even files! My desktop system at home (and my parent's and my uncle's and whatnot) are completely stand-alone desktop systems, connected to the Internet, with no LAN. They only need to talk to their (serial or USB connected) printer, that's all! I'm surprised that the over-bloat of Windows' desktop is now considered to be the good way of doing things. :-( Javier signature.asc Description: Digital signature
Re: avahi-daemon
(IMHO this dicussion is reaching to a point in which it should move to d-devel instead, but I'll keep it here) On Thu, Mar 02, 2006 at 09:06:27PM +0100, Loïc Minier wrote: On Thu, Feb 23, 2006, Javier Fernández-Sanguino Peña wrote: IMHO the problem here is having a music program (as rhythmbox) Recommends: avahi-daemon, when IMHO it should be Suggests: . The functionality provided by avahi-daemon (a network service for sharing music) is not something I would say that all rhythmbox users require (based on rhythmbox' description, which looks like a music library organization tool for me). However, it will get it installed per default by users using 'aptitude' (not 'apt') which is the recommended tool these days. It would be overly complicated to handle the case of a Suggests instead of a Recommends correctly: even if the code was updated to handle both Overly complicated? You are overestimating it. It's as simple with a Suggests: as with a Recommends: (people still use 'apt-get' which does not pull in Recommends: automatically). The software cannot rely on it being installed so it should check if the thing it needs is there, if it's not then it asks the user to install it. This can be an error in STDERR (as it is now, I believe) but, more elegantly, could be a window message instructing users what to do and what they gain (and lose) if they do (or don't). It's not that complicated. cases at run time, and would hide the relevant options when these are not available, the documentation would still point at unavailable features. So? The whole point of documentation is to tell people how to do stuff. Rhythmbox' section on Share music should start with You need to have installed for this feature to work. That's it. As simple as that. And the popup mixing application level information with package level information would also be awful: You should install package foo to get this functionality. That's been done for ages. Let me bring you a new use case for your consideration (recent in my mind) and related to Suggests/Recommends and enhanced program functionality of another (buggy) program which is music related. First, I would like you to take a look at the ITU's statistics (available at http://www.itu.int/ITU-D/ict/statistics/), you can see there that the average number of PCs per *100* habitants for European countries (in the year 2004) is 28.48 [1] Based on that, you could assume that having more than one computer per household is not all that common. So, I *believe* that your average computer home user is typically going to extract music from CDs (to listen in their computer or on other devices, like MP3 players) more, on average, than sharing with neighbour PCs. Now, take a look at Grip (install it), it's an application to extract audio data from CDs. Grip is useless unless you install additional encoders. If you don't have them (and there are in it's Suggests: or Depends:) then the software should instruct you to go and install them. Grip fails to do so properly, and people bug it often. There's no MP3 encoder in the Debian archive, what should Grip do then? a) suggest: or recommend: inexistant packages [2] b) download and install an MP3 encoder on installation from somewhere lease c) subrepticiously package an mp3 encoder in the Debian package and bypass the FTP masters d) fail to work, and tell user that he cannot find an encoding program e) document the fact that there are no MP3 encoders in Debian and that you have to fetch them somewhere else IMHO, it should do d) and e) not try to be smarter than the user and do a), b) or c) just for the sake of plug and play. It fails to do so properly (there is no documentation regarding the lack of MP3 encoders in Debian) and so it get bugged to oblivion. Should have it taken the plug and play option, b) or c), it could probably work out of the box, but then it would be violating an (unwritten) Debian policy, right? Do you see still think that the argument for the sake of Plug Play, for the sake of the average user should brandished in front of people as an excuse for not doing things properly? You might as well get the issue documented in the RB BTS if you want, I'll simply link to this thread where I clearly state that I think it's a desirable feature which should be working by default. :) I don't agree with you here and if I get to see avahi being installed in a default GNOME install in Debian and will make damn sure that I get to see it removed. The dep was strict because RB wouldn't start without it. Now it will start, but with a warning. I'm quite sure you can get it to crash if avahi isn't there though, but that's a bug. Then it's a bug, and it should be fixed in RB. The avahi-daemon is nicely chrooted, and runs under a different user. You just can't have the functionality of plug'n'play on a network without any central server without listening at some point to
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
Re: avahi-daemon
On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote: Well, no: that's the opposite of plug'n'play. See, if you're USB stick contains a malicious vfat file system, it gets automatically mounted nevertheless. It's a feature. Not in my servers, it doesn't. And I should add, not even in my desktops: all removable filesystems are mounted nodev, nosuid. Oh, and that was certainly the default when you pulled in GNOME? Mounting malicious filesystems automatically (vfat can't be one AFAIK, but it won't bork if you tell it to be nosuid, nodev either) is never a feature, it is a security hole. vfat and iso9660 had holes in the FS drivers themselves recently IIRC. Actually, should we not file security bugs against everything that comes configured to mount removable filesystems out-of-the box and does so without specifying nodev, nosuid ? Think just before that: it's not only the mount options, it's the simple mounting which is risky. It's not music sharing, it's listening on the network. Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote: True. But that requires a broken kernel, which we patch regularly as a security procedure anyway. Mounting removable filesystems suid,dev allow a lot more damage *by design* in the standard Linux security-model. And we also support avahi security-wise, and would patch it in the case of a knwon vulnerability. -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, 03 Mar 2006, Loïc Minier wrote: On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote: True. But that requires a broken kernel, which we patch regularly as a security procedure anyway. Mounting removable filesystems suid,dev allow a lot more damage *by design* in the standard Linux security-model. And we also support avahi security-wise, and would patch it in the case of a knwon vulnerability. Nobody ever implied that avahi is badly maintained. And unless mdns/avahi is somehow being shipped configured in such a way so as to allow for immediate local root priviledge escalations, I don't think I understood the point you wanted to make. I stated that the fact that an hipotetic kernel bug *also* allows for local root exploits through a nosuid,nodev removable filesystem does *not* excuse us to have removable filesystems being mounted suid,dev, which depending on the filesystem type allows for immediate local root privilege escalation, *by* *design*. Current Earth status: NOT DESTROYED How fortunate, that ;-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, 03 Mar 2006, Loïc Minier wrote: On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote: Well, no: that's the opposite of plug'n'play. See, if you're USB stick contains a malicious vfat file system, it gets automatically mounted nevertheless. It's a feature. Not in my servers, it doesn't. And I should add, not even in my desktops: all removable filesystems are mounted nodev, nosuid. Oh, and that was certainly the default when you pulled in GNOME? I have purged GNOME in deference to their lousy practices, so I wouldn't know. KDE tried to do that for a while, but it seems to have disabled it again (or it is buggy). And I am probably going to raise the issue with the package maintainers as soon as I have the time to verify the status of all the automounting packages in Debian, which will take a while. If their default is suid,dev, that will have to change. Actually, should we not file security bugs against everything that comes configured to mount removable filesystems out-of-the box and does so without specifying nodev, nosuid ? Think just before that: it's not only the mount options, it's the simple mounting which is risky. It's not music sharing, it's listening on the network. If automounting of removable filesystems is defaulting to enabled, that will also be an issue to be addressed, sure. But music sharing isn't designed to allow for local root exploits, is it? Mounting unix-compatible filesystems in dev,suid modes is. If you're worried we are holding mdns apps to a different standard, don't. It's just a matter of what is in the radar right now ;-) I will have to check first if the kernel is taking some extra care, as that might reduce the number of affected packages. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Fri, 03 Mar 2006, Loïc Minier wrote: 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. You will notice I didn't propose you disable open ports by default. What part of ask it using debconf, priority medium or higher, default can be enabled tells you do not have open ports for mdns open by default? 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. They did, just like the multimedia people. Will you push me in reverting any argument you provide in favor of security the other way around, or is my point sufficiently clear? See first paragraph reply. Please, bring solutions in this discussion, not arguments, we've got enough already. See first paragraph reply. 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). Well, that has more to do with avahi-server than your mdns app. And if you look for the thread, you will notice I replied to whomever asked that that avahi-server should start automatically like just every other daemon in Debian does, that it made sense to bind avahi-server to IPADDR_ANY, and to use policy-rc.d if you don't want stuff like that hapenning. But this still does not mean mdns apps should not have the mdns master switch. Unless they *need* avahi-server installed and active to even open a mdns socket, in which case they don't need to implement anything (the master switch is avahi-server). 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. Leave it at Medium, it is enough. Avahi mdns isn't high risk (this does not apply to zeroconf, but I understand that avahi mdns clients and avahi-server are a different kettle of fish). I don't know between priority medium and low. I should probably look at existing debconf-handled settings to get a picture. Setting it at low defeats the purpose of the question. The idea is that it is a *master* switch, no matter how many avahi client apps you install, you get asked only for the first one. Since there are (no matter how slight) security implications, most installs should see it (thus priority medium). 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. It is mentioned as an example that others do *something* to avoid listening on outside interfaces. At least to me it is very obvious that in avahi's case it doesn't make sense to listen on lo only. You *could*, for a more difficult implementation than the master switch, ask instead in which interface should avahi servers and clients listen (and allow for the none reply). I don't think that's worth the trouble, however, so I didn't suggest it at first. 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. That's probably the way to go, as it is much better implemented as a shared debconf template, and avahi's master packages seem the better place to document it, at the very least. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
Loïc Minier wrote: It would be overly complicated to handle the case of a Suggests instead of a Recommends correctly: even if the code was updated to handle both cases at run time, and would hide the relevant options when these are not available, the documentation would still point at unavailable features. And the popup mixing application level information with package level information would also be awful: You should install package foo to get this functionality. Standard Desktop task installs do not install Recommends anyway, so rhythmbox does not pull in avahi-daemon in those situations and you need to deal with that somehow. -- see shy jo signature.asc Description: Digital signature
Internal trusted networks? (was Re: avahi-daemon)
On Fri, Mar 03, 2006 at 06:47:34PM +0100, Loïc Minier wrote: Hi, On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote: 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 don't think you have seen many corporate (i.e. hundreds of nodes) networks. I've seen a few, and, from my limited experience: a) people in charge of switches do not belong to the IT security department (there's a whole communications department for level 2 and even inter network routing) b) it is not possible to set per-port ACLs for traffic since services are not completely defined (are you sure that the people in management don't have to access the file servers at engineering?) and there's just too many end nodes (with new ones being introduced and old ones removed from the network continously) c) there are multiple routing entities in the network (not just the border router) due to having multiple interconnected LANs (some really nasty and *big* networks are a single LAN, but that's difficult to handle). So the needed visibility for a host is more than just a single router. d) ACLs in core routers (think Cisco Catalyst) only buy you so much security-wise (it might prevent IP spoofing but they are not, after all, stateful filters) and has performance considerations (specially if you are running Gigabit) So even if the security people as you so put it, would recommend per-port ACL allowed traffic they would (and do) get shunned by other IT departments. At most, IT security can get a bridge firewall [1] setup between sensible networks to isolate and try to control traffic between them. 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. With people bringing laptops (and all kind of devices) from the outside of the network, unprotected/uncontrolled WiFi access points, etc. there is no such thing as an internal trusted network. Regards Javier [1] Some call it IPS, but then again, that's were the hype now is... or was... you never now. signature.asc Description: Digital signature
Re: avahi-daemon
Hi, On Thu, Feb 23, 2006, Javier Fernández-Sanguino Peña wrote: IMHO the problem here is having a music program (as rhythmbox) Recommends: avahi-daemon, when IMHO it should be Suggests: . The functionality provided by avahi-daemon (a network service for sharing music) is not something I would say that all rhythmbox users require (based on rhythmbox' description, which looks like a music library organization tool for me). However, it will get it installed per default by users using 'aptitude' (not 'apt') which is the recommended tool these days. It would be overly complicated to handle the case of a Suggests instead of a Recommends correctly: even if the code was updated to handle both cases at run time, and would hide the relevant options when these are not available, the documentation would still point at unavailable features. And the popup mixing application level information with package level information would also be awful: You should install package foo to get this functionality. If I were you (aliban) I would bug rhythmbox. It seems that Bug #349478 got it to reduce the Depends: on that daemon to a Recommends:, I think it would be better to have that as Suggests: Disclaimer: I don't know much about rhythmbox and the relationship of ahavi-daemon You might as well get the issue documented in the RB BTS if you want, I'll simply link to this thread where I clearly state that I think it's a desirable feature which should be working by default. :) The dep was strict because RB wouldn't start without it. Now it will start, but with a warning. I'm quite sure you can get it to crash if avahi isn't there though, but that's a bug. Maintainers remember: it's much better to *not* install/activate a network service than to have a service, even if it's chrooted, or running under lower privileges (like the ahavi maintainers describe in https://wiki.ubuntu.com/MainInclusionReportAvahi) which, BTW, is not that common. The keyword here is 'exposure'. The avahi-daemon is nicely chrooted, and runs under a different user. You just can't have the functionality of plug'n'play on a network without any central server without listening at some point to something... Really, do *almost all* rhythmbox users need to share music (and consequentely need ahavi)? That's not the point, the point is to make it easy to do so. And yes, a lot of users share music between computers. Those people want that to be simple. You can't cut every feature out because only 10% of the users use it. It's not like you're running Rhythmbox on a firewall, and iptables is still there, you can remove avahi, you can configure it not to start etc. Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Wed, Feb 22, 2006 at 08:59:40AM -0800, Rick Moen wrote: Quoting aliban ([EMAIL PROTECTED]): MS Blaster infected many million system within seconds... Relying on the vulnerable MSDE embedded SQL database engine being embedded into a large number of consumer software products, and irresponsibly left bound to all network ports, not just loopback. You are confusing worms, Blaster exploited the DCOM RPC vulnerability (CAN-2003-0352). The one that exploited CAN-2002-0649 and CAN-2002-1145 in both SQL Server and MSDE was SQLExp / Slammer. The former worm targeted a critical OS service, the later a database service. Neither of which were actually useful if bound to loopback, BTW. IMHO the problem here is having a music program (as rhythmbox) Recommends: avahi-daemon, when IMHO it should be Suggests: . The functionality provided by avahi-daemon (a network service for sharing music) is not something I would say that all rhythmbox users require (based on rhythmbox' description, which looks like a music library organization tool for me). However, it will get it installed per default by users using 'aptitude' (not 'apt') which is the recommended tool these days. If I were you (aliban) I would bug rhythmbox. It seems that Bug #349478 got it to reduce the Depends: on that daemon to a Recommends:, I think it would be better to have that as Suggests: Disclaimer: I don't know much about rhythmbox and the relationship of ahavi-daemon I agree with Michael Stone in that the dependecy chain here might be a problem in the long run. Maintainers remember: it's much better to *not* install/activate a network service than to have a service, even if it's chrooted, or running under lower privileges (like the ahavi maintainers describe in https://wiki.ubuntu.com/MainInclusionReportAvahi) which, BTW, is not that common. The keyword here is 'exposure'. Really, do *almost all* rhythmbox users need to share music (and consequentely need ahavi)? Regards Javier signature.asc Description: Digital signature
Re: avahi-daemon
On Thu, Feb 23, 2006 at 12:04:50PM +0100, Javier Fernández-Sanguino Peña wrote: The former worm targeted a critical OS service, the later a database service. Neither of which were actually useful if bound to loopback, BTW. Actually, they were. A lot of the embedded DB servers were only used by local applications (e.g., IIRC, a virus scanner) and never made use of the network in normal applications. And *a lot* of standalone systems were vulnerable to the DCOM thing even though they weren't (intended to be) managed over the network. That's exactly the danger in making assumptions about how things are going to be used. -- Michael Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
Javier Fernández-Sanguino Peña schrieb: If I were you (aliban) I would bug rhythmbox. It seems that Bug #349478 got it to reduce the Depends: on that daemon to a Recommends:, I think it would be better to have that as Suggests: Disclaimer: I don't know much about rhythmbox and the relationship of ahavi-daemon I agree with Michael Stone in that the dependecy chain here might be a problem in the long run. Maintainers remember: it's much better to *not* install/activate a network service than to have a service, even if it's chrooted, or running under lower privileges (like the ahavi maintainers describe in https://wiki.ubuntu.com/MainInclusionReportAvahi) which, BTW, is not that common. The keyword here is 'exposure'. I am sorry, but I am quite new linux and debian at all and you may excuse my question: why is there no rule to prompt the user for all applications that open ports on non-localhost? I guess in most cases these services will be configured afterwards anyway to fit admin's needs. In example if you install apache (I did not do so, maybe it is prompting:) why shouldn't the install script ask what interfaces to bind to? On my 'default' system I would not want any open ports at all :/, do you? Or do you think I am paranoid? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Thu, Feb 23, 2006 at 12:47:44PM +0100, aliban wrote: I am sorry, but I am quite new linux and debian at all and you may excuse my question: why is there no rule to prompt the user for all applications that open ports on non-localhost? The default policy is a compromise between convenience and security. Debian has opted for convenience (services are enabled per default) and strives to have people do it properly (services are run as unprivileged users, with a minimun configuration to make them functional).. In some instances (only a few packages, mostly base/important) users are given a change to disable them on installation (or, even,, but most others services are enabled per default. Some services (which cannot be properly configured automatically) are left off until you configure them and enable them manually, but there are not that many of those. The philosophy is: if you installed it from a binary package then you wanted it to be acive, if you don't want it to be active then either introduce a policy that says don't enable it on install, or disable it manually post-install, or don't install a binary package (pick up the sources or the -doc packages instead if you just want to see how it works). You can find more information in http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.6 and http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html (FAQ Question 11.1.14.1 Why are all services activated upon installation?) HTH Javier signature.asc Description: Digital signature
Re: avahi-daemon
Quoting Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]): You are confusing worms, Blaster exploited the DCOM RPC vulnerability (CAN-2003-0352). The one that exploited CAN-2002-0649 and CAN-2002-1145 in both SQL Server and MSDE was SQLExp / Slammer. True. Thank you, and apologies for my misrecollection. -- Cheers, Rick Moen Anger makes dull men witty, but it keeps them poor. [EMAIL PROTECTED] -- Elizabeth Tudor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
The package maintainer has a point that an mDNS daemon would be pretty pointless if it only bound to lo. I think it is more the responsibility of the administrator to know what is going on his system. If you are so worried about security, then why not check out those NINE new Avahi packages when apt says they are going to be installed? If you miss it there, it is very prominently displayed on startup that the Avahi daemon is starting. Oh noes! I'd better stop that and figure out exactly what it is. If you interested in a security report on Avahi, Ubuntu has one here. https://wiki.ubuntu.com/MainInclusionReportAvahi This is a service aimed at desktop use. If you're worried about it getting installed on a server, then you shouldn't be installing a music player on it either. You're contradicting yourself on your levels of paranoia. On 2/22/06, aliban [EMAIL PROTECTED] wrote: Hi, as the package maintainer seems to ignore my complaint I forward the discussion to debian-user mailing list. On debian testing the rhythmbox suggested to install the avahi-daemon that listens on all interfaces by default. I think this kind of install behaviour is insecure even if the package maintainer does not agree. In short I think: even if the user should know what he is doing when he updates his system it is not a secure design for packages to start listening on all interfaces by default without prompting AND warning the user. It is not sufficient to mention this behaviour somewhere in the package description as many packages come as a dependency or as a suggested package; users wont read every package description of every package they install, especially if they come as a suggested package or dependency. best regards. Sjoerd Simons schrieb: On Mon, Feb 20, 2006 at 11:22:29PM +0100, Aliban wrote: Package: avahi-daemon Version: 0.6.6-1 Severity: normal I don't know why this pkg was installed in my testing. For sure I did not install it directly, maybe it was some strange dependency from something? No strange dependencies. You probably got it because rhythmbox recommends it. Yes, I think that was the reason. Anyway, this thing listens on all interfaces by default. I think this design is insecure. It should bind to localhost only (ok, this might not make sense for such a service) OR it should ask the user for the interfaces it binds to. Uhm, yeah, well, an mDNS daemon that only listens on lo is completely useless. If you would looked a little bit further you might have seen that the daemon runs as a unprivileged user, version 0.6.6-2 of the package even runs in a minimal chroot environment, so it's actually quite secure by design. I don't doubt that it has a quite secure design. Anyway, as soon as something starts listening on the network this is a potential security hole. In contrast to applications that are only contacting the internet on user's demand (in example a webbrowser, email client or instant messenger) this thing is always on and not depending on additional user interaction, therefore it is a different level of 'taking care'. Please change the installer's behaviour. If you don't want it, purge it from your system. Afaik everything that doesn't directly need it only recommends it. Closing this bug Sjoerd I did not have problems to remove it from the system, I just wonder why something gets installed and opens a port and starts listening to all interfaces without asking me, esspecially if I did not directly ask for this program. Do you really expect all users to read every line of every program description? When you install Adobe or Java from sun, did you read every single word in the license? Would you like it if Adobe just opens some 'obscure' service listening on all interfaces? Of course it does not make sense to install this daemon and listen only on local host. Maybe the maybe the recommending should be removed but this is another thing... Anyway, all I think is that users should be prompted (in example as portmap does it). I suggest you add something like xyz is a service that does blah blah, ... For most users this service should bind only to a local area network and not to the internet. (If you need this service at all) Do you want to bind to all interface? - with no as default! I would be very happy if you can add such a thing. What do you think? Edrin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
I don't think so. Are you god? Even if the administrator makes mistakes and does not check what gets installed the system should be designed save. In this case you are doing the same mistakes Microsoft did with Windows all the time: default installation comes with a 'strange' service (that nobody needs, therefore nobody knows) sitting somewhere around and listening on ALL interfaces. This is the reason why all these worms, i.e. MS Myblast, owned all the systems. And this is paranoid? In general a non-localhost interface is a security problem thus don't open ports by default esspecially if this is some strange thing coming 'hidden' as a suggested pkg of a normal program. An installation system should be responsible for the unexperienced users as well. An experienced user will know how to activate this thing while the unexperienced user is not even aware of this problem. I suggest the pkg promts with something like xyz is a service that does blah blah, ... For most users this service should bind only to a local area network and not to the internet. (If you need this service at all) Do you want to bind to all interface? - with no as default! (btw. i found it so don't blame me with your argument) Daniel Givens schrieb: The package maintainer has a point that an mDNS daemon would be pretty pointless if it only bound to lo. I think it is more the responsibility of the administrator to know what is going on his system. If you are so worried about security, then why not check out those NINE new Avahi packages when apt says they are going to be installed? If you miss it there, it is very prominently displayed on startup that the Avahi daemon is starting. Oh noes! I'd better stop that and figure out exactly what it is. If you interested in a security report on Avahi, Ubuntu has one here. https://wiki.ubuntu.com/MainInclusionReportAvahi This is a service aimed at desktop use. If you're worried about it getting installed on a server, then you shouldn't be installing a music player on it either. You're contradicting yourself on your levels of paranoia. On 2/22/06, aliban [EMAIL PROTECTED] wrote: Hi, as the package maintainer seems to ignore my complaint I forward the discussion to debian-user mailing list. On debian testing the rhythmbox suggested to install the avahi-daemon that listens on all interfaces by default. I think this kind of install behaviour is insecure even if the package maintainer does not agree. In short I think: even if the user should know what he is doing when he updates his system it is not a secure design for packages to start listening on all interfaces by default without prompting AND warning the user. It is not sufficient to mention this behaviour somewhere in the package description as many packages come as a dependency or as a suggested package; users wont read every package description of every package they install, especially if they come as a suggested package or dependency. best regards. Sjoerd Simons schrieb: On Mon, Feb 20, 2006 at 11:22:29PM +0100, Aliban wrote: Package: avahi-daemon Version: 0.6.6-1 Severity: normal I don't know why this pkg was installed in my testing. For sure I did not install it directly, maybe it was some strange dependency from something? No strange dependencies. You probably got it because rhythmbox recommends it. Yes, I think that was the reason. Anyway, this thing listens on all interfaces by default. I think this design is insecure. It should bind to localhost only (ok, this might not make sense for such a service) OR it should ask the user for the interfaces it binds to. Uhm, yeah, well, an mDNS daemon that only listens on lo is completely useless. If you would looked a little bit further you might have seen that the daemon runs as a unprivileged user, version 0.6.6-2 of the package even runs in a minimal chroot environment, so it's actually quite secure by design. I don't doubt that it has a quite secure design. Anyway, as soon as something starts listening on the network this is a potential security hole. In contrast to applications that are only contacting the internet on user's demand (in example a webbrowser, email client or instant messenger) this thing is always on and not depending on additional user interaction, therefore it is a different level of 'taking care'. Please change the installer's behaviour. If you don't want it, purge it from your system. Afaik everything that doesn't directly need it only recommends it. Closing this bug Sjoerd
Re: avahi-daemon
Hi, On Wed, Feb 22, 2006, aliban wrote: as the package maintainer seems to ignore my complaint I forward the discussion to debian-user mailing list. I am the package maintainer of Rhythmbox, am I the package maintainer you refer to? Or did you mean the avahi-daemon package manager? On debian testing the rhythmbox suggested to install the avahi-daemon that listens on all interfaces by default. It used to Depend on it (ie. MUST install avahi-daemon to be able to install rhythmbox), but this has been downgraded to Recommends (ie. in some rare cases, it might be legitimate not to install it and face the consequences). If you feel paranoid, you can uninstall avahi-daemon, but don't complain that music sharing doesn't work. I think this kind of install behaviour is insecure even if the package maintainer does not agree. Are you building a secure machine? Are you running Firefox and browsing web pages written by strangers? Security is not only about not listening on any port. The default Debian distribution doesn't come with an iptables rule denying all traffic (inbound and outbound), you're free to add it. If you do install a GNOME desktop environment, expect to have a web browser which might run malicious code, games which might be sgid games, and tons of stuff which might be opening more doors than you like. In short I think: even if the user should know what he is doing when he updates his system it is not a secure design for packages to start listening on all interfaces by default without prompting AND warning the user. It is not sufficient to mention this behaviour somewhere in the package description as many packages come as a dependency or as a suggested package; users wont read every package description of every package they install, especially if they come as a suggested package or dependency. People want more features, people want a working desktop by default, people want their USB key mounted automatically when it's connected, even if it might trigger some malicious vfat code, they want their iPod synced automatically with the library by default, they want to see network shares by default, they want to be able to share their data, be it via DAAP, SMB, or DAV... What you want is the opposite of plug and play: closing all doors and requiring people to open N doors to use a high-level feature such as music browsing is *not* intuitive. Parts of this discussion are available in #349478. Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Wed, Feb 22, 2006, aliban wrote: In this case you are doing the same mistakes Microsoft did with Windows all the time: Please, no generalities. default installation comes with a 'strange' service (that nobody needs, therefore nobody knows) sitting somewhere around and listening on ALL interfaces. This is the reason why all these worms, i.e. MS Myblast, owned all the systems. And this is paranoid? Most Windows virii propagate via email, and I'm not sure Evolution is way safer than Outlook, still it is the recommended mail client under GNOME, it doesn't listen on any interface, but is quite probably a major security hole. You're free not to use it, not shipping it would leave us without a high-level calendar + tasks + mail + schedule + meetings + groupware application. I suggest the pkg promts with something like xyz is a service that does blah blah, ... For most users this service should bind only to a local area network and not to the internet. (If you need this service at all) Do you want to bind to all interface? - with no as default! In the case of a discovery daemon, this is useless. Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Wed, Feb 22, 2006 at 03:23:42PM +0100, Loïc Minier wrote: If you do install a GNOME desktop environment, expect to have a web browser which might run malicious code, games which might be sgid games, and tons of stuff which might be opening more doors than you like. First, there's a difference between passive and active attacks. We can't prevent people from doing dangerous things with their computers, but we can try to keep their computer from being a danger all by itself. From a pragmatic standpoint, pulling in nss-mdns is a PITA because it makes certain name queries take forever--so there are reasons aside from security to think this is annoying. Securitywise, there is no doubt in my mind that this mdns stuff will open a lot of new vulnerabilities in the future--the history of this sort of service suggests that it is inevitable. Making it easy to pull in and activate as a side effect of apparantly-unrelated packages is, IMO, a mistake. What you want is the opposite of plug and play: closing all doors and requiring people to open N doors to use a high-level feature such as music browsing is *not* intuitive. The real question is whether installing gnome should mean that you get multicast dns. I'll bet that the number of people who want the former is significantly larger than the number who want (or know they're getting, or even care about) music browsing. -- Michael Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Wed, Feb 22, 2006, Michael Stone wrote: From a pragmatic standpoint, pulling in nss-mdns is a PITA because it makes certain name queries take forever--so there are reasons aside from security to think this is annoying. (nss-mdns does mdns too, but it's not related to avahi) Securitywise, there is no doubt in my mind that this mdns stuff will open a lot of new vulnerabilities in the future--the history of this sort of service suggests that it is inevitable. Making it easy to pull in and activate as a side effect of apparantly-unrelated packages is, IMO, a mistake. From a security point of view, everything feature introduce risk. If you base all you reasonning on security, that is if you make security rule number 1, you get zero feature. I do agree that is is slightly different in that it adds a passive hole as soon as the package is installed in contrast with packages being dangerous when used by end-users. The real question is whether installing gnome should mean that you get multicast dns. I'll bet that the number of people who want the former is significantly larger than the number who want (or know they're getting, or even care about) music browsing. You can't take the decision to remove a feature because most people install GNOME for other reasons than that feature. Otherwise one would use the same reasonning for all features in GNOME and remove them all. But I agree with the former part: the question is do we support multicast DNS or not? When I look at the results of my mdns queries here, I have no doubt it will soon be a requirement since I see: - computers - a music remote control interface - music shares - HTTP and SSH servers (that's less common) - administrative interface for wifi APs Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
Loïc Minier schrieb: Hi, On Wed, Feb 22, 2006, aliban wrote: as the package maintainer seems to ignore my complaint I forward the discussion to debian-user mailing list. I am the package maintainer of Rhythmbox, am I the package maintainer you refer to? Or did you mean the avahi-daemon package manager? No, I don't think you are responsible for this. the package manager of avahi-daemon. But this is more a general discussion/complaint :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
Loïc Minier schrieb: On Wed, Feb 22, 2006, aliban wrote: In this case you are doing the same mistakes Microsoft did with Windows all the time: default installation comes with a 'strange' service (that nobody needs, therefore nobody knows) sitting somewhere around and listening on ALL interfaces. This is the reason why all these worms, i.e. MS Myblast, owned all the systems. And this is paranoid? Most Windows virii propagate via email, and I'm not sure Evolution is way safer than Outlook, still it is the recommended mail client under GNOME, it doesn't listen on any interface, but is quite probably a major security hole. You're free not to use it, not shipping it would leave us without a high-level calendar + tasks + mail + schedule + meetings + groupware application. That's true, most virii propagate via email. I was talking about a worm that can spread without user-interaction in example the MS Blaster (sorry, not MyBlast): W32.Blaster.Worm is a worm that exploits the DCOM RPC vulnerability The difference between security holes in webbrowsers/email clients and something like the DCOM RPC vulnerability is that webbrowsers and email clients must be ACTIVLY used while a listening *something* needs no user interaction and is PASSIVE. The result is: - With a vulnerable webbrowser you must surf the wrong webpage. - With an vulnerable email client you must have a mainstream email client to get infected with high probability, otherwise an email worm wont spread enough. (In example Outlook) In additional most email virii need a user that will click clickme.exe - With a passive vulnerable listening application (that is installed to listen to the internet by default) you must just wait for the ... bad day. While the email worm needs new email addresses to find new victims a worm exploiting a vulnerable listening service just has to ping randomly IPs... MS Blaster infected many million system within seconds... I suggest the pkg promts with something like xyz is a service that does blah blah, ... For most users this service should bind only to a local area network and not to the internet. (If you need this service at all) Do you want to bind to all interface? - with no as default! In the case of a discovery daemon, this is useless. Cheers, Not really; in example would you want to bind netbios/samba to internet? If I would write worms my perfered exploits would be remote exploits that does not depend on user interaction in any way. regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
Quoting aliban ([EMAIL PROTECTED]): MS Blaster infected many million system within seconds... Relying on the vulnerable MSDE embedded SQL database engine being embedded into a large number of consumer software products, and irresponsibly left bound to all network ports, not just loopback. Don't Do That, Then.tm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Wed, 22 Feb 2006, aliban wrote: On debian testing the rhythmbox suggested to install the avahi-daemon that listens on all interfaces by default. That's on par with the avahi-daemon's idea of how things should happen, and it makes sense. Not that I'd want that active in my LAN anyway. If you don't want services to start before you have manually verified them, even if you install a package (by accident or whatever), then write an appropriate policy-rc.d (see /usr/share/doc/sysv-rc/README.policy-rc.d) to do just that. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: avahi-daemon
On Wed, Feb 22, 2006 at 04:57:26PM +0100, Loïc Minier wrote: On Wed, Feb 22, 2006, Michael Stone wrote: From a pragmatic standpoint, pulling in nss-mdns is a PITA because it makes certain name queries take forever--so there are reasons aside from security to think this is annoying. (nss-mdns does mdns too, but it's not related to avahi) No? Package: avahi-daemon Source: avahi Version: 0.6.7-1 Depends: libavahi-common3 (= 0.6.4), libavahi-core3 (= 0.6.0), libc6 (= 2.3.5-1), libcap1, libdaemon0, libdbus-1-2 (= 0.60), libexpat1 (= 1.95.8), adduser, dbus (= 0.60) Recommends: libnss-mdns The dependency chains here get a little scary. From a security point of view, everything feature introduce risk. If you base all you reasonning on security, that is if you make security rule number 1, you get zero feature. And if you introduce questionable features with huge security implications without thinking them through you get a real mess which is going to take a lot of work down the road to clean up. There's a real danger inherent in focusing on a particular bit of functionality and ignoring its larger implications, *especially* in a project as large as debian. You can't take the decision to remove a feature because most people install GNOME for other reasons than that feature. Otherwise one would use the same reasonning for all features in GNOME and remove them all. Your logic is frankly questionable. Anytime you start with a proposition like making that decision equates to removing every possible feature you're probably making a logical leap. But I agree with the former part: the question is do we support multicast DNS or not? When I look at the results of my mdns queries here, I have no doubt it will soon be a requirement since I see: - computers - a music remote control interface - music shares - HTTP and SSH servers (that's less common) - administrative interface for wifi APs I don't see any of those appearing on any network I maintain. I've now trumped your assertion with one of my own, do I win something? On any *managed* network I don't think that having stuff like this appear out of nowhere is particularly beneficial. On a small home network I'm not convinced it buys you anything because you're not generally dealing with enough stuff to need a service location solution. I'm sure its potentially very useful on geeky home networks with lots of systems and services, but I'm not sure that's a reasonable basis for a default configuration. -- Michael Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
