On Sat, Aug 02, 2003 at 02:22:27PM -0500, Manoj Srivastava wrote: > On Sat, 2 Aug 2003 14:50:16 -0400, Matt Zimmerman <[EMAIL PROTECTED]> said: > > First, no one would _need_ to discuss this because it is only a > > recommendation (though a wise one). > > Again, a recommendation, about issues that would require > changes in the program to change the situation, may not be a good > thing for policy.
The same thing applies to most of the recommendations for discussion which are in the policy manual today, and I see no problem with it. In fact, the effects on the program are exactly the same as the recommendation in 10.9: The rules in this section are guidelines for general use. If necessary you may deviate from the details below. However, if you do so you must make sure that what is done is secure and you should try to be as consistent as possible with the rest of the system. You should probably also discuss it on `debian-devel' first. > The developers reference is a compendium of best practices and > good things to do, which is what this seems to be. Why should this recommendation be relegated to the developer's reference, while others are in the policy manual? The developer's reference describes its packaging practices (chapter 6) with the sentence "These are just some subjective hints, advice and pointers collected from Debian developers. Feel free to pick and choose whatever works best for you." I consider setuid/setgid permissions to be an important packaging consideration, not a subjective hint. My interpretation of the difference between policy and the developer's reference is that the policy manual tells me how to avoid creating a buggy package, while the developer's reference provides hints that have helped others in maintaining their packages. Security vulnerabilities, and practices which make packages susceptible to as-yet-undiscovered vulnerabilities, are bugs. The policy manual already contains a section describing the required and recommended permissions for files owned by Debian packages, which seems a logical place for a recommendation to discuss certain sensitive issues relating to permissions for files owned by Debian packages. It even discusses setuid and setgid programs. My goal in placing the recommendation there is to place it where a Debian developer would see it when deciding what permissions to use for programs in their package. > > Second, your comment about the package depending on being setid is > > irrelevant. Obviously, no program which does NOT depend on being > > setid should be made setid, but it should be discussed in any case. > > What good does this discussion do, if program functionality > does indeed depend on being set{u,g}id? If the security team were to > audit these packages, well, there would be something. But I > understand the security team is already overlaoded, and I would not > wish additional work on wther people. It has already happened several times in the past that when I have had the opportunity to review a package with a setuid/setgid program that I have been able to discuss with the maintainer and avoid introducing a security vulnerability into Debian. This not only makes less work for the security team in trying to support insecure or improperly configured software, but it improves the overall quality of the distribution. This is an example of the good that can come from such a discussion, based on what has already happened in the past. All that I am asking is that Debian prominently recommend to developers that they give me, and developers in general, the chance to perform this review, so that I can help to improve the security of the distribution. > > Often, I believe that the discussion will determine whether or not > > it truly depends on being setid. > > That would be really hard to do, unless soneone gets into the > nitty gritty of the code and determines it is not. On what experience do you base this assumption? I have often found security bugs in a program within seconds of starting to look at the code. Other times, it is obvious that a program is being granted setuid privileges unnecessarily. Refer to DSA-299, DSA-310 and DSA-330 for concrete examples of preventable vulnerabilities. This kind of mistake is easy to catch if the situation is brought up for discussion, but usually it is not, and that is what I would like to change. > > I do not understand why you are presenting such hostile opposition to a > > well-intentioned proposal for recommending discussion. > > Hostile? That is _your_ characterization. Why is it that any > disagreement with a proposal is automatically hostile? Why do you > perceive any proposals you make to be quite so adversarial a > process? Yes, it is my characterization, based on your comments. No, this does not apply to any disagreement, but specifically to your disagreement in this instance. No, I do not perceive any proposals I make to be so adversarial. I perceive you to be adversarial when I politely correct you, present a clarification, and ask "what is your objection?" and you reply with "You are being disengenuous" and "Making the dir world writable is not a solution". The former being insulting and untrue, and the latter a gross misrepresentation. > > A dictionary both would tell you the correct spelling of the word > > "disingenuous", and demonstrate that it does not accurately describe > > my words which you quoted above. > > Ah, a spelliong flame. How jejune. Moreever, you choise to > characterize the fact that a program is setgid as merely a packaging > matter -- as though just putting another line in the rules file > (chmod blah 755) would make the problem go away. Disingenuous > indeed. I wouldn't have bothered correcting your spelling except as an adjunct to addressing the insult that it represented. Coincidentally, your straw man example is almost exactly what happened in DSA-299. My arguments are clear, concrete and based on examples from real-world experiences, and my goal is to reduce security workload and to improve the quality of Debian. There is nothing the least bit disingenuous about my statements. > > I AM PROPOSING THAT: > > > - The policy manual include a recommendation for discussion on > > debian-devel before a new setuid or setgid program is added to the > > Debian archive, whether included for the first time or by change > > of permission on an existing program > > Does -devel have final say in the packaging or acceptance of > the program into the project (in case of an ITP)? The only way to get > in a new setgid games program into the project is to get a consensus > on debian-devel? Or perhaps a GR? Is this process an integral part of > packaging and getting a program into the project? None of these questions apply to a setuid/setgid recommendation for discussion any more or less than they apply to a recommendation for discussion of pre-depends, essential: yes, using permissions other than those recommended in section 10.9, etc. > If not, I still think it is better placed in > developers-reference. If you want to get consensus on debian-devel as > an integral part of getting packages accepted into debian, you may > need more than just a policy proposal. The idea is not to obtain a ruling by popular vote, but to provide for peer review. > > What are you talking about? The proposal was to recommend discussion; > > there was no proposal of world writable directories of any kind. > > Well, if the rpogram is run by multiple people, and can write > a shared file as any user, and it is not to be setgid, or setuid, how > elese would you achieve that end? A world writable dir is the logical > conclusion of needing vsarious users creating, and modifying, shared > files without a set{u,g}id program. There are other solutions, including group membership, but it doesn't matter, because that is not what I am talking about. The fact is, many programs run with privileges that they do NOT require in order to function acceptably, or even fully, and I want to promote discussion in order to prevent that situation. -- - mdz