Re: setuid/setgid binaries contained in the Debian repository.
On Sat, Aug 02, 2003 at 02:22:27PM -0500, Manoj Srivastava wrote:
> On Sat, 2 Aug 2003 14:50:16 -0400, Matt Zimmerman <mdz@debian.org> 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
Reply to: