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: first A record of security.debian.org extremely slow
* Quoting Marc Haber ([EMAIL PROTECTED]): On Thu, Mar 02, 2006 at 11:09:28PM +0100, Florian Weimer wrote: I typically use an Exim .forward file which invokes a special script using pipe. The script creates a file, and a cron job which runs periodically checks for the existence of that file and performs the desired action when it exists. This means that DSA sent in quick succession only trigger the action once. So you have debian-security subscribed on all systems, and all systems need to run a publicly reachable mail system? You can trigger the update via ssh or wget. - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: first A record of security.debian.org extremely slow
On Fri, Mar 03, 2006 at 11:11:30AM +0100, Rolf Kutz wrote: You can trigger the update via ssh or wget. The entire scheme strikes me as reinventing a mechanism which has been existing for years now, being called cron-apt. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- 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: first A record of security.debian.org extremely slow
On Fri, Mar 03, 2006 at 11:13:52AM +0100, Marc Haber wrote: On Fri, Mar 03, 2006 at 11:11:30AM +0100, Rolf Kutz wrote: You can trigger the update via ssh or wget. The entire scheme strikes me as reinventing a mechanism which has been existing for years now, being called cron-apt. I don't believe it does. Cron-apt is a pull mechanism (download the latest packages, check if there are upgrades and notify the admin). A mail filter which parses the DSAs and tells people to update is a push mechanism. Notice that in the later (push) you could have somebody review if the update is critical enough, or only tell systems to upgrade once the patch has been tested internally. That seems easier to me than, in the pull system, set up an intermediate mirror of security.debian.org with *approved* updates, have the systems update automatically and have a sysadmin move the updates from the official mirror over to that internal mirror based on whether the update is critical or not. Also, in my mind's view, a push mechanism is bound to be more effective than probing the security mirror daily and could also be capable of narrowing the time between patch release and installation (if automated) since you don't have to wait for a given point in time to make the check. Florian, in any case, I see no mentioning of where those scripts being available. Are they? Regards Javier signature.asc Description: Digital signature
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]
Bonk vulnerability!
I just installed a server with sarge 3.1 and after testing it with nessus it is vulnerable to bonk. I am trying to figure out how that is possible and how to fix it? My other servers are not vulnerable to bonk. I run a debian shop. Thanks for any insight, ZK __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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: Bonk vulnerability!
--On March 3, 2006 10:01:54 AM -0800 Zakai Kinan [EMAIL PROTECTED] wrote: I just installed a server with sarge 3.1 and after testing it with nessus it is vulnerable to bonk. I am trying to figure out how that is possible and how to fix it? My other servers are not vulnerable to bonk. I run a debian shop. Thanks for any insight, I've no idea WTF 'bonk' is, having never heard of it before, but I'll bet it's a badly written nessus plugin or just a plugin that's false positive-ing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bonk vulnerability!
On Fri, 2006-03-03 at 13:01 -0700, Michael Loftis wrote: --On March 3, 2006 10:01:54 AM -0800 Zakai Kinan [EMAIL PROTECTED] wrote: I just installed a server with sarge 3.1 and after testing it with nessus it is vulnerable to bonk. I am trying to figure out how that is possible and how to fix it? My other servers are not vulnerable to bonk. I run a debian shop. Thanks for any insight, I've no idea WTF 'bonk' is, having never heard of it before, but I'll bet it's a badly written nessus plugin or just a plugin that's false positive-ing. http://www.urbandictionary.com/define.php?term=bonk I really don't see why being vulnerable to bonk is such a bad thing. I wouldn't mind being a bit more susceptible, myself. -davidc -- Who is General failure and why is he reading my disk? -- 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
Re: Bonk vulnerability!
Oh, that is cute. Bonk is similar to teardrop. I was able to use nessus plugin to crash the sarge 3.1 server. ZK --- David Clymer [EMAIL PROTECTED] wrote: On Fri, 2006-03-03 at 13:01 -0700, Michael Loftis wrote: --On March 3, 2006 10:01:54 AM -0800 Zakai Kinan [EMAIL PROTECTED] wrote: I just installed a server with sarge 3.1 and after testing it with nessus it is vulnerable to bonk. I am trying to figure out how that is possible and how to fix it? My other servers are not vulnerable to bonk. I run a debian shop. Thanks for any insight, I've no idea WTF 'bonk' is, having never heard of it before, but I'll bet it's a badly written nessus plugin or just a plugin that's false positive-ing. http://www.urbandictionary.com/define.php?term=bonk I really don't see why being vulnerable to bonk is such a bad thing. I wouldn't mind being a bit more susceptible, myself. -davidc -- Who is General failure and why is he reading my disk? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bonk vulnerability!
--On March 3, 2006 1:55:14 PM -0800 Zakai Kinan [EMAIL PROTECTED] wrote: Oh, that is cute. Bonk is similar to teardrop. I was able to use nessus plugin to crash the sarge 3.1 server. Did it actually crash or did nessus just report one? If it crashed what was the Ooops onscreen? This is dubious at best since I'm not aware of any variant of Linux that is susceptible to this attack, and no box I've got here is (3.0, 3.1, RH, SuSE) If your machine is crashing it's probably completely unrelated to 'bonk' and is either a driver issue or hardware issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
