On Sat, 2 Aug 2003 14:50:16 -0400, Matt Zimmerman <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> 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
indeed.
> You, on the other hand, seem to be misrepresenting or
> misunderstanding me. Let me clarify very explicitly:
> 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?
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.
manoj
--
One man's folly is another man's wife. Helen Rowland
Manoj Srivastava <[EMAIL PROTECTED]> <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
