[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: setuid/setgid binaries contained in the Debian repository.

On Sat, 2 Aug 2003 14:50:16 -0400, Matt Zimmerman <mdz@debian.org> said: 

> On Sat, Aug 02, 2003 at 12:49:06PM -0500, Manoj Srivastava wrote:
>> On Sat, 2 Aug 2003 13:09:09 -0400, Matt Zimmerman <mdz@debian.org>
>> said:
>> > No, we are talking about recommending that developers discuss
>> > with other developers before making a change to their package
>> > which is
>> So, we do not need to discuss this if there is no change being
>> made, ie, packages which are already setgid games? Or if the
>> package being newly inducted depends on being sgid?

> 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 developers reference is a compendium of best practices and
 good things to do, which is what this seems to be. 

> 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. 

> 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.

>> > likely to affect the security of every system where the package
>> > is installed.  File permissions and program privileges are
>> > clearly a packaging matter.  What is the nature of your
>> > objection?
>> 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.

> 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? 

> 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

> You, on the other hand, seem to be misrepresenting or
> misunderstanding me.  Let me clarify very explicitly:


> - 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? 

	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.

	A trojanned single user program run by root that sends out
 /etc/shadow is far worse than losing the top ranking in pacman.

>> Making the dir world writable is not a solution, and indeed, is
>> worse for security.

> 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.

One man's folly is another man's wife. Helen Rowland
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: