On Fri, 2010-05-14 at 22:22 -0700, Russ Allbery wrote: > These are really odd complaints to bring against Debian given that these > are not Debian issues. Firefox, for example, works exactly the same way > everywhere. What do you want Debian to do, write our own web browser? > There are limits to what a distribution can do. Again, these are just example where things could be secured.... I do of course not want to Debian write it's own browser, but we already patch some of them "quite heavily", don't we? E.g. firefox to support all the plugin-packages stuff? > For example, here, you don't appear to understand that we're talking about > the user umask, which should not be affecting system services, "should not"... well... I guess this isn't a proof, is it? We've had so many examples of things that happened although they should not. udisks should have probably not exported the dm-crypt keys to normal users, but it did. Many scripts (don't remember a concrete example now) should have probably set a secure PATH, but they forgot to do so, and were attackable. sudo should have probably been secure, but it wasn't.... and if we would have added normal users to sudoers (like Ubuntu does as far as I know), "everything" would have been vulnerable. The openssl issue should have probably just solved some valgrind errors (wasn't that the idea of those patches?) but it lead probably to the great disaster in cryptography in the last years... > If regular users can add other people to groups on your system, you have > way more serious security problems than user-private groups, and those > security problems are not created by Debian. Of course I talk about having this done by root. It seems you do not have experience with systems with several thousands of users, do you? If I'm e.g. a root user at my university, or an empowered registration authority for CERN,... I really cannot check whether what my users ask is sane. If user B says, please add user A to my group... I'll do it as long as no system user/group is involved. Not to talk about the fact what happens, if at one day one wants to move away from UPGs... > And here, you appear to have completely misunderstood the purpose of > user-private groups in exactly the way that I tried to explain earlier. > If there is anyone in a user-private group other than the user > corresponding to it, you have broken user-private groups and created a > security hole on your system. Yes I know... (the concept of them is really not so difficult to understand, is it?) > But that's your misconfiguration, not > something Debian did. Honestly,... real world is different... see my example above in big organisations, consider the fact that users have typically no idea what they doing... And even if you don't consider... What we had now, was already kind of semi-UPGs wasn't it? - Everybody had his private group, which others could be added to. - But if others were added, they did not automatically have rwx-rights on basically everything. With a default of 022: The owner of the file has to manually decide to make a file writeable by the members of his UPG, right? Isn't that much secure as the other way round? With a default of 077: It'd be even better, as the owner does not only have to deliberately decide for write, but also for read rights. > and every distribution picks something and leaves that to site policy, > rightfully. 022 is the "standard" default choice, and I think it's more > appropriate for a free software distribution, although I know that by > itself is a moderately controversial statement. IMHO, we generally should not do something, because any other distro is doing it. We should simply do the right. So let me make clear, that I don't decline 002 because of "other distributions have 022",... I decline it because I consider it to be inherently insecure. > I'm paranoid by profession, and I'm still in the 022 camp, so I don't > think this is a clear-cut decision. You meant you're in the 002 camp, didn't you? > A umask of 002 with UPG is almost completely equivalent to a umask of 022 > without UPG. Only if everything works perfectly right. All software and so on. Typically not the case... > gamin is a superior implementation of the idea of fam for several reasons, > one of them being that it doesn't require portmap at all. If you're > concerned with security, I encourage you to uninstall fam and install > gamin and then stop worrying about this. Well I also use gamin,.... but I guess people should be free to choose, and still be on a safe side. > > You need it for nfs-common... now you say one probably want's to have it > > then listening to all interfaces,... but I can imagine that people > > install it just because nfs is such a common thing and they want to have > > the manpages in place. > That seems like a rather questionable thing to do and then complain about > the security stance of the distribution. Why? I typically have e.g. openssh-server installed just to get the manpages, but have the service itself disabled, where I don't need it. > > But maybe on needs NFS, and needs it just a several places, or very > > rarely. Such people want to have the packages installed, but perhaps > > disable it (portmap) per default and just enable it, when they really > > need it? > > If you're sophisticated enough to do that, you're sophisticated enough to > configure it to listen only to localhost. It's not like it's hard. Again, with that argument,.. "if one can do it, let's "open" it and it's still ok".... we can basically justify any security-hole that we open up. > You do realize that MD5 is still secure against preimage attacks and > replacing MD5 in an existing protocol (as opposed to when designing a new > protocol) is only warranted if you're anticipating a collision attack or > if it's a fairly trivial amount of work, right? Yes I do,.. it's really not necessary to ask at every topic, whether I understand it or not.... Even though no pre image attack against MD5 is known (at least not publicly ^^)... it's broken,... we know for years now that it has major limitations,... so why continue to use it, if there are better alternatives. I can imagine only very limited reasons that would really justify to use it... Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature