Re: setuid/setgid binaries contained in the Debian repository.
On Sat, 2 Aug 2003 16:55:12 -0400, Matt Zimmerman <mdz@debian.org> said:
> 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.
Hmm. Discuss is a far cry from requiring consensus, or permission.
>> > 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.
You are reiterating what I said -- someone with security
experience reviewed the program, and that produced results. If people
are there who have the time, inclination, and expertise to review
these programs, then I would agree with you.
> 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
Common sense. See, I am going to tell you that /usr/bin/bar in
package foo needs to be really, truly, cross my heart setgid baz;
since it maintains a common set of files owned by baz and shared
between any user of the machine.
Without looking at the code, how can you tell that it does not
need the privilege?
> 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 have brought /usr/bin/bar up for discussion now. I am
anxious to see how it can be improved by this discussion.
Anyway, if it is all that simple and sensible, Why do we need
policy to tell us to do normal, sensible, security related things?
>> > 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.
Seems to me I started out by asking whether this proposal
would be a better fit for the developers reference, and, when asked,
expanded on why I thought so.
From where I stand, sure feels like you have a chip on your
shoulder when it comes to this proposal.
> 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.
This, sir, is a lie.
I did not call you disingenuous for asking for clarification, I
called you disingenuous for stating that setgidness of programs is
merely a packaging issue; and implying that program design and
implementation were not involved.
>>>>>>>>>>> File permissions and program privileges are clearly a
>>>>>>>>>>> packaging matter. What is the nature of your objection?
I would suggest you go back and look at the emails in question
again. I replied:
>>>>>>>>>>> You are being disengenuous. If a program needs to write
>>>>>>>>>>> files shared by other users when it is run (save files,
>>>>>>>>>>> high score files, macro definitions), and uses a group
>>>>>>>>>>> writable directory (after taking precautions internally
>>>>>>>>>>> that the files being written ought to be written to,
>>>>>>>>>>> etc), just changing the file permissions without changing
>>>>>>>>>>> the program shall render the program unusable.
Obviously, something that is just a packaging issue can be
handled by changing the packaging process (adding lines to the rules
file).
Let us get down to specific examples, then: One such setgid
package I am familiar with is angband; andband writes data files,
user and class macros, save files, and high scores in
/var/games/angband. Whenever the user edits some files in
/etc/andband/*; files in /var/games/angband/data/* are modified by
the program the next time it runs; and these files are then used by
all subsequent invocations.
You think that the setgidness of this binary is merely a
packaging issue? I'd be happy to get a patched rules file that would
allow me to do away with the setgid angband binary.
>> > 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.
If my pointing out that you were miscasting setgid programs as
``packaging issues'' is insulting, what does that make your initial
misrepresentation, then?
> Coincidentally, your straw man example is almost exactly what
> happened in DSA-299.
And the fix was to just package the code differently?
> 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.
The disingenuity comes from the statement that these are just
superficial packaging matters -- instead of often complex fixes to
the underlying code.
>> > 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.
In the case of something proposed as essential, while the
question is being discussed, the package is in the project, and is
providing utility to the users.
If this is used as a gating mechanism, then ITP'd packages
shall be in limbo until someone gets around to providing the proper
penguin pee to bless its entrance into unstable.
> There are other solutions, including group membership, but it
If there is a group games, and people who want to play games
are made a member, then this is less securew than the current setgid
solution; since any program run by any user can now modify any files
writable by the group games.
If it is one group per game, you have potentially thousands of
groups, and maintianing registry of who wants to play what when would
be even more of a nightmare, and still not provide as good a
protection to scores files and other game artifacts as the current
solution does on a multi user machine.
> doesn't matter, because that is not what I am talking about. The
Good, because this was a poor solution.
> 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.
Why do we need policy to tell us to do what you suggest are
good, common sense things?
manoj
--
Procrastination is the art of keeping up with yesterday. George Carlin
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: