Re: setuid/setgid binaries contained in the Debian repository.
On Sun, 3 Aug 2003 23:52:57 -0400, Joey Hess [EMAIL PROTECTED] said: Manoj Srivastava wrote: Policy can make it so that packages are not accepted into Debian unless you hop through certain hoops. Like making sure the upload has a signature. Or that it has an entry in the override file. No, those have nothing to do with policy and are implemented solely at the ftp master's discretion. If I had intended to gate setuid binaries from debian, I would have posted to debian-cabal, not debian-devel. If it is policy to prevent setuid programs to get in to the archive without consensus on the devel list, I am sure ftp admin would have no difficulty implementing the solution. I am sorry for having believed that the proposed draft meant what is seemed to say, given that it would have, with everyone agreeing, gone into the policy document as it stood -- making it a bug not to have achieved consensus on -devel. Are you saying that the review was not discussed as a gating mechanism? If that is the case, then I admit I, for one, was fooled. Message-ID: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] All set[ug]id setups should be reviewed before they go into the archive. Manoj, you have misquoted Matt here. After the word archive, he put not a period, but the rest of his sentence. If you read the whole thing: I absolutely support this idea. All set[ug]id setups should be reviewed before they go in the archive, and I volunteer to do the review (though I hope that others will help). Does this need a proposal to go into policy with the same force as the existing pre-depends verbiage? Does in no way change the point I made in my excerpt: given the language of the policy diff, it is not unreasonale to think that the the should is meant in policy terms. As I said, I sure was fooled. I guess I am just perverse. Matt is here, I belive, expressing a heartfelt opinion that it would be good for us to find security problems before they become *our* security problems. Moreover he's volenteering to do work. If his use of should was not satisfactory, well, he was not making a formal policy poposal either. I'm willing to cut people who do work a lot more slack than those who impede it. As I have said before, I have no beef with programs being audited. My point, from the beginning, was that the proposal seemed to talk about consensus on the list, and seemed to state it was a bug not to have achieved such a consensus. Rather than telling me that program permissions were packaging matters, I could simply have been told that the language of the draft was not to be interpreted in terms of the policy document. Despite your belittling comments, one of the tasks I have undertaken is to ensure the quality of the policy document; and this was supposed to be a draft of a policy change. However, I am used to having work on policy being considered mere bureaucracy, and impediments in the way of the worker bees. So be it. The idea is not to only be nice and freindly to yes men, but also to be able to discuss rationally with people who do not share your view, without bringing in ridiculously insulting strawmen like hopping on one foot. One of my rules of thumb is to stop replying to threads when my opponents resort to terms they learned in debating class, or to misquoting, since nothing good ever comes of it. Bye. Disparaging remarks from you are kosher, but terms from debating class (since I never took any, I can only suppose you mean strawmen) are not. Fine. Your call. manoj -- The destruction of the Berlin wall marked history's first feminine revolution: There had been no violence and when it ended everybody went shopping. 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
Re: setuid/setgid binaries contained in the Debian repository.
* Manoj Srivastava | Why do we need policy to tell us to do what you suggest are | good, common sense things? Because common sense isn't as common as it should be. Not even among DDs. :( -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003, [iso-8859-2] Micha³Politowski wrote: On Fri, 1 Aug 2003 19:19:10 +1000, Matthew Palmer wrote: [...] From my investigations, I thought that the intended use of dpkg-statoverride was by the local administrator, modifying the default suid/sgid and ownership of the file as set in the package tarball. This is also my understanding. Still, some packages do use it for better or worse reasons. One example I've just found in uml-utilities.postinst: if ! getent group uml-net /dev/null; then addgroup --quiet --system uml-net fi if ! dpkg-statoverride --list /usr/lib/uml/uml_net /dev/null; then dpkg-statoverride --update --add root uml-net 04750 \ /usr/lib/uml/uml_net fi There are plans to remove this nescessity, by having the preinst add the user/group, and having the deb contain the dynamic permissions itself. This would mean all packages that current Depend on adduser would have to Pre-Depend on it. It also requires some changes to dpkg-deb.
[OT:HUMOR] Re: setuid/setgid binaries contained in the Debian repository.
On Sat, 2 Aug 2003, Manoj Srivastava wrote: It is? OK, I am telling you /usr/bin/bar program in package foo really needs to be sgid. I'll document it in bar.6. Is this the end of discussion? Or are we going to really need to look at the code to see if the setgidness can be worked around? Hmm, package foo is buggy. bar should be in /usr/games.
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, 2 Aug 2003, Manoj Srivastava wrote: Why do we need policy to tell us to do what you suggest are good, common sense things? Oh come on. You honestly think there is common sense in this project? Not everyone is as smart, brilliant, and perfect as you. If there was common sense, we wouldn't need policy nor any other document.
Re: setuid/setgid binaries contained in the Debian repository.
On Sun, 3 Aug 2003, Manoj Srivastava wrote: Policy can make it so that packages are not accepted into Debian unless you hop through certain hoops. Like making sure the upload has a signature. Or that it has an entry in the override file. I can easily code an entry for katie and friends that takes a new package, and marks up the ones with setgid bits set -- and the ftp maintainers do not create override entries until they see a consensus develop, or the security team says ok. No, this is not debian-policy. Having such a signature, or an override file entry, has nothing to do with package's interaction with the rest of the system. These items are only for accepting a package upload into the debian archive. You have said in various avenues that policy is only to be used for documenting interactions between packages; yet, you then bring up this point, and say it's a policy issue. For gods sake, come up with some more intelligent arguments for your point of view. Don't change the facts to fit your personal view of the debian universe.
Re: setuid/setgid binaries contained in the Debian repository.
On Sun, Aug 03, 2003 at 10:04:09PM -0500, Manoj Srivastava wrote: I can easily code an entry for katie and friends that takes a new package, and marks up the ones with setgid bits set -- and the ftp maintainers do not create override entries until they see a consensus develop, or the security team says ok. You could, but it wouldn't be useful as a filter, because it would not notice packages which set the permissions in postinst (as does every package with a dynamic uid). Note that this is NOT what was proposed. While I think this might be a useful methodology in the future, I do not think that it makes sense until the review process has established itself in a less fascist manner. Are you saying that the review was not discussed as a gating mechanism? If that is the case, then I admit I, for one, was fooled. Message-ID: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] All set[ug]id setups should be reviewed before they go into the archive. I do not understand how you logically reach gating mechanism from my should above. None of the other should statements in the policy manual are interpreted this way. How did I fool you? -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Sun, Aug 03, 2003 at 11:58:13PM -0500, Manoj Srivastava wrote: As I have said before, I have no beef with programs being audited. My point, from the beginning, was that the proposal seemed to talk about consensus on the list, and seemed to state it was a bug not to have achieved such a consensus. I would not object to clarification of the reference to consensus. What I want is a chance for me and others to review these programs in order to find obvious vulnerabilities and related packaging errors. If there are such problems, then I do not need the support of policy to declare that the package is buggy and inform the maintainer. If this process happens before the package enters the archive, then the maintainer has a chance to fix the bugs before uploading it (or before it is accepted), and this is a considerably better situation than finding out after the fact and scrambling to fix vulnerabilities in software which we are distributing to a huge number of users. That is the justification for requesting this notification before the package enters the archive, and not any idea of a gating mechanism. Rather than telling me that program permissions were packaging matters, I could simply have been told that the language of the draft was not to be interpreted in terms of the policy document. Program permissions are, in fact, packaging matters, especially those which affect security. The policy manual already discusses these concerns, for example in section 11.11: Some packages, for example some fortune cookie programs, are configured by the upstream authors to install with their data files or other static information made unreadable so that they can only be accessed through set-id programs provided. You should not do this in a Debian package: anyone can download the `.deb' file and read the data from it, so there is no point making the files unreadable. Not making the files unreadable also means that you don't have to make so many programs set-id, which reduces the risk of a security hole. This is a classic example of the kind of packaging problem which could be easily spotted by a review with a focus on security. Making a program setuid should raise flags which cause developers to ask Why does this program require setid permissions? How can I minimize the risk of this configuration?. Since often developers do not think of this at the time, I am suggesting that they should raise the issue for discussion so that others will ask these questions and propose solutions. -- - mdz
/usr/games, FHS 2.2 (Re: setuid/setgid binaries contained in the Debian repository.)
On Mon, Aug 04, 2003 at 10:33:59AM -0500, Adam Heath wrote: On Sat, 2 Aug 2003, Manoj Srivastava wrote: It is? OK, I am telling you /usr/bin/bar program in package foo really needs to be sgid. I'll document it in bar.6. Is this the end of discussion? Or are we going to really need to look at the code to see if the setgidness can be worked around? Hmm, package foo is buggy. bar should be in /usr/games. (mercilessly dragging this message back on-topic) I've never understood the purpose of /usr/games. It seems to be gone in FHS 2.2. Speaking of which, are there any plans to review FHS 2.2 for inclusion in Debian policy? -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Sun, Aug 03, 2003 at 10:57:51AM +0900, Oohara Yuuma wrote: I don't care if you mandate a prior peer view _request_ (not prior approval) This is what was proposed, except that it was recommended rather than mandated. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, Aug 02, 2003 at 08:58:00PM -0500, Manoj Srivastava wrote: Given the last review of a setgid program, I wonder if two people are enough. Surely two people would be an improvement over the current situation, where there is no review at all. Our demonstration has shown how one person can discover some common flaws with a relatively brief review. This bug and others existed in your package for over four years (and still exist in stable today). We might still not know about it if you had not brought the package to my attention for review. Steve Kemp might have eventually discovered it in the course of his auditing, but I don't know whether he is spending his time on non-free software such as angband. Keep in mind that there are also potentially more than two people interested in this review process. Another person besides myself has already volunteered in just the first day of discussion, and I find this very encouraging. The mistake was simple, human, and undesrtandable, but the review does not in fact talk about any flaws in the current version of angband The review, simplistic though it was, uncovered flaws in the package in stable which were overlooked by the maintainer. This kind of situation is often preventable through discussion and code review, as you have seen. I would like to promote this beneficial process within Debian in order to reduce the workload of the security team and the presence of vulnerabilities in our stable releases. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, Aug 02, 2003 at 08:58:00PM -0500, Manoj Srivastava wrote: Given the last review of a setgid program, I wonder if two people are enough. The mistake was simple, human, and undesrtandable, but the review does not in fact talk about any flaws in the current version of angband (tome does need to be so changed); and this kind of error would undermine the process -- especially if the results are couched in terms like those below: I think it's accepted that no matter how many people look at a piece of code that there may be things missed. There are programs I've examined in the past which I believed were OK only to later see that they contained flaws. It's easy to imagine things would still be overlooked with more people looking at the code, so a false positive review would occur. However what's the worst that could happen? If there were a team and they messed up we'd have a vulnerable program in the archive which is exactly what we have now. If something were spotted then it could be fixed and we'd have reached a better degree of security than that which we currently enjoy. Given the time it would take for a few people to look over a program I think it's a reasonable suggestion, and worth doing even if it doesnt catch *everything*. Steve --- pgp5MhTeqFMFt.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Sun, Aug 03, 2003 at 03:14:23AM -0400, Matt Zimmerman wrote: Surely two people would be an improvement over the current situation, where there is no review at all. Our demonstration has shown how one person can discover some common flaws with a relatively brief review. *Exactly*. Well said. Keep in mind that there are also potentially more than two people interested in this review process. Another person besides myself has already volunteered in just the first day of discussion, and I find this very encouraging. I find that very pleasing also. I have no desire to go down a *BSD route and audit every single thing, (mostly due to a lack of time), but it's good to see that there are people interested in this kind of work. I would like to promote this beneficial process within Debian in order to reduce the workload of the security team and the presence of vulnerabilities in our stable releases. I did feel a little guilty when reporting so many issues that I was putting unfair pressure upon the security team to release fixes, but I assumed if that were the case somebody would tell me. Anything that could make it easier for the security team to do their job is a good thing as you do such a good and important job. Thanks to all of you. Steve --- pgpDAvsb7jebr.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
Manoj Srivastava wrote: Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. In certian cultures, including mine, gratutious repitions of ones point is considered childish and rude and something most of us outgrow by age 6. Anyway, you seem to be arguing that policy cannot make mandates that require significant changes to the source or behavior of programs, which is not true at all. Policy requires that packages bt FHS compliant; this often means large changes to the endire organisation of packages, including large source code changes and design changes. (See the space-orbit package for a good example.) Policy asks that window managers support the debian menu system, this has required significant changes in the code of less-capable window managers such as twm. Policy requires that everything in debian use the same backspace/delete keyboard mapping, which requires changes all over the place. Policy requires that programs not depend on environment variables to function, which can easily mean that a program's source code must be changed to make it read a config file instead. These are just a few examples. -- see shy jo pgp6RKrEq44xi.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
Matt Zimmerman wrote: 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. Just for example, I sat down and audited mooix's user of setuid and setgid bits the other day. When I started, mooix contained 3 interactive setuid root programs, 2 setuid helper programs with well-defined and very small user inputs, and one daemon that ran as root. When I finished, mooix contained 3 programs setuid and/or setgid to users and groups with limited permissions, 3 setuid helper programs, and one daemon that drops permissions to nobody after it's done with PAM. Overall 300 fewer lines of code run as root. And better gains that this are possible in many other packages in debian. -- see shy jo pgpPvaGTOXtiE.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Sun, 3 Aug 2003 03:14:23 -0400, Matt Zimmerman [EMAIL PROTECTED] said: On Sat, Aug 02, 2003 at 08:58:00PM -0500, Manoj Srivastava wrote: This bug and others existed in your package for over four years (and still exist in stable today). We might still not know about it if you had not brought the package to my attention for review. Steve Kemp might have eventually discovered it in the course of his auditing, but I don't know whether he is spending his time on non-free software such as angband. You note that the bugs have been fixed over a year ago. The review, simplistic though it was, uncovered flaws in the package in stable which were overlooked by the maintainer. This kind of situation is often preventable through discussion and code review, as you have seen. I would like to promote this beneficial process within Debian in order to reduce the workload of the security team and the presence of vulnerabilities in our stable releases. I haven't objected to code reviews of packages; I objected to gathering consensus through discussion; and making admission of new packages incumbent on such consensus. Now, if this proposal is all about getting the code reviewd, and it is merely a recommendation, as you have implied recently, then change the stated wording to reflect that. manoj -- You can measure a programmer's perspective by noting his attitude on the continuing viability of Fortran. Alan Perlis 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
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, 2 Aug 2003 22:17:16 -0400, Matt Zimmerman [EMAIL PROTECTED] said: On Sat, Aug 02, 2003 at 08:14:15PM -0500, Manoj Srivastava wrote: Heh. You should look at what is in the current version: Is that what you would say to the users who have angband installed on Woody? I do not think this is something to laugh about. There are any number of old programs where security was not an issue -- and yes, angband is one where such a makeover was only performed in the last year. I must confess that my security audits did not include angband; I was more concerned with my packages in Debian, and I should have paid more attention to angband earlier. manoj -- It is a wise father that knows his own child. William Shakespeare, The Merchant of Venice 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
Re: setuid/setgid binaries contained in the Debian repository.
On Sun, 3 Aug 2003 11:59:03 -0400, Joey Hess [EMAIL PROTECTED] said: In certian cultures, including mine, gratutious repitions of ones point is considered childish and rude and something most of us outgrow by age 6. I would much rather you restricted your responses to the substance of the discussion, rather than attacking the style and culture of the respondent; this project is supposed to have a multicultural membership: all the world is not american, and I think people may need to learn to live with that. Anyway, you seem to be arguing that policy cannot make mandates that require significant changes to the source or behavior of programs, which is not true at all. Not without a transition plan in the general case. And my point, which you have not addressed, was that most of your examples were not ones that mandated significant changes to the source or behavior of programs. Policy requires that packages bt FHS compliant; this often means large changes to the endire organisation of packages, including large source code changes and design changes. (See the space-orbit package for a good example.) Surely you recall the time that was afforded developers to accomplish the /usr/doc - /usr/share/doc change? We did not mandate FHS compliance with a simple change to policy mandates. Policy asks that window managers support the debian menu system, this has required significant changes in the code of less-capable window managers such as twm. Policy requires that everything in debian use the same backspace/delete keyboard mapping, which requires changes all over the place. Policy requires that programs not depend on environment variables to function, which can easily mean that a program's source code must be changed to make it read a config file instead. These are just a few examples. First, most of these alloowed people time to bring their programs in line. Secondly,, no new programs were kept out of the distribution by requiring an audit and a consensus on debian-devel; You got the program in, and you worked on the bugs that were filed on it. Using a policy directive as a gating mechanism has never, ever been done. manoj -- Diplomacy is to do and say, the nastiest thing in the nicest way. Balfour 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
Re: setuid/setgid binaries contained in the Debian repository.
On Sun, 3 Aug 2003 00:16:59 -0400, Matt Zimmerman [EMAIL PROTECTED] said: On Sun, Aug 03, 2003 at 10:57:51AM +0900, Oohara Yuuma wrote: I don't care if you mandate a prior peer view _request_ (not prior approval) This is what was proposed, except that it was recommended rather than mandated. The proposal makes it a bug if you do not manage to achieve consensus (not a rough consensus -- a flat out consensus) on debian-devel. manoj -- Loose bits sink chips. 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
Re: setuid/setgid binaries contained in the Debian repository.
Manoj Srivastava wrote: Not without a transition plan in the general case. And my point, which you have not addressed, was that most of your examples were not ones that mandated significant changes to the source or behavior of programs. First, most of these alloowed people time to bring their programs in line. Secondly,, no new programs were kept out of the distribution by requiring an audit and a consensus on debian-devel; You got the program in, and you worked on the bugs that were filed on it. So by analogy, the debian-legal list should not be able to block new software with potentially bad licenses from entering the archive. Instead we should have some kind of teansition plan. Fascinating, tell me more. -- see shy jo pgpZk3K3CKWlV.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
Manoj Srivastava wrote: I haven't objected to code reviews of packages; I objected to gathering consensus through discussion; and making admission of new packages incumbent on such consensus. Again, how is this different from the debian-legal mailing list? -- see shy jo, amazed at the phrase I objected to gathering consensus through discussion pgpI0EX8ee04j.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Sun, 3 Aug 2003 13:24:13 -0400, Joey Hess [EMAIL PROTECTED] said: Manoj Srivastava wrote: Not without a transition plan in the general case. And my point, which you have not addressed, was that most of your examples were not ones that mandated significant changes to the source or behavior of programs. First, most of these alloowed people time to bring their programs in line. Secondly,, no new programs were kept out of the distribution by requiring an audit and a consensus on debian-devel; You got the program in, and you worked on the bugs that were filed on it. So by analogy, the debian-legal list should not be able to block new software with potentially bad licenses from entering the archive. Instead we should have some kind of teansition plan. Fascinating, tell me more. *Sigh*. I didn't think I would need to tell you about our social contract, nor that you would find that exposition fascinating. Since even you appear to be confused about this distinction, perhaps I should not be making assumptions about other readers of this list. Hmm. See, we have this thing called the social contract, which we all agreed to, and which is one of the core things about Debian. The social contract provides a guideline to determine what we call free. That is hard at times to do, so we have a bunch of people, who, in the goodness of their heart, donate time to help people determine how to apply those guidelines. I also note that the -legal list does have gating rights over every package; they mostly respond to request from maintainers who are confused about some license. Packages are not held up until the list provides the proper penguin pee. There is no dictum in policy to beat people on the head with to make them go to the list and get consensus. It is one thing to have a clearinghouse where expertise lives, and to have that clearinghouse offer expert services when a developer is in doubt, and quite another to use policy to ram these volunteer services down every ones throats. Did you find this as elucidating as my previous message? Manoj Srivastava wrote: I haven't objected to code reviews of packages; I objected to gathering consensus through discussion; and making admission of new packages incumbent on such consensus. Again, how is this different from the debian-legal mailing list? Again, there is nothing in policy that requires a consensus on the -legal mailing list in order for packages to be included in the project. If I am confused about a license, yes, the -legal list exists to disambiguate the license; and help me decide whether it should or should not be in Debian. No beating me on the head with policy at all. Is this distinction really so hard to see? I would be enthusiastically for a list like -legal, where people can go and ask for help to have packages audited, but not for people rolling up policy to beat people on the head to make it so. manoj -- Keeping proprietary and confidential information secret is the key to moving the computer industry into the 21st century. Letter from Apple Computer and Rasterops to the Macintosh user community 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
Re: setuid/setgid binaries contained in the Debian repository.
Manoj Srivastava wrote: I would be enthusiastically for a list like -legal, where people can go and ask for help to have packages audited, but not for people rolling up policy to beat people on the head to make it so. Perhaps your confusion stems from me using a non-normative should in the draft text of the proposal. Of course a policy SHOULD cannot mandate developer behavior outside a package, as I alluded to in my very first reply to you. If that's all you're objecting to, you've chosen a really counterproductive way to do it, since you've merely managed to piss off me and several other people who are actually interested in doing some work. Bear in mind that policy appropriates perfectly common and valid English for its own uses, and this is very easy to stumble over when writing proposals. I for one, have a history of stumbling over it multiple times in the past, and I expect to continue to do so until policy is fixed to use uppercased normative words or something like that. -- see shy jo pgpxwDFKu6MrY.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Sun, 3 Aug 2003 18:53:34 -0400, Joey Hess [EMAIL PROTECTED] said: Manoj Srivastava wrote: I would be enthusiastically for a list like -legal, where people can go and ask for help to have packages audited, but not for people rolling up policy to beat people on the head to make it so. Perhaps your confusion stems from me using a non-normative should in the draft text of the proposal. Of course a policy SHOULD cannot mandate developer behavior outside a package, as I alluded to in my very first reply to you. Well, when someone proposes a patch to policy, with a properly created patch against current policy, then of course the normal assumption is that the person was using should as policy normally does. How can one tell otherwise? If that's all you're objecting to, you've chosen a really counterproductive way to do it, Really? I recall starting off with a question. I said this seems like a good practice kind of thing, and whether it should be dev reference material. Just the thing to get people pissed off, eh? I followed up with mentioning that it was not just nethack, other games were also affected, and that, unlike the implication in the original patch, there was more than discussion required, help would be needed to modify programs if setgid was not acceptable. So far, I am 6-7 mails into the discussion, and I have been quiet, polite and asking for explanations. Then you brought up a bunch of examples about recommendations in policy, and I pointed out that those cases were different, since program code and behaviour, or program design, were often not involved. Then mdz said something about this is all just packaging, and I protested. So far, I fail to see what exactly has been said (until the disingenuous remark) that is so very counterproductive. Perhaps I was not so off the mark when I talked about chips on the shoulder? I note that later discussion tried to paint this whole process as getting people involved in auditing code, and not a mandatory requirement (ie, if you do not get a consensus then your package is buggy) that was in the original proposal. I have a full log of this email conversation, as indeed do the list archives, so just go back and lok the whole thread up. since you've merely managed to piss off me and several other people who are actually interested in doing some work. If I pissed you folks off, then rest assured that the contrary was also true, but I am not going to whine about people on this mailing list annoying me or hurting my poor, beleaguered ego. The conversation degenerated due to little jabs and pin pricks from all around; which unfortunately seems to be the cost of doing business in this mailing list -- unless, of course, you muzzle your own opinions and follow the herd. So either get a thicker skin, or do not expect petulant mails to me to not get the treatment they deserve. I always start of politely, and would never get confrontational unless in reaction (hi aj). As for doing work in reviewing packages, I would not be disinclined to do so -- though that was a neat jab, couching this disagreement in terms of crusty old loafer pissing off the hard working folks. Bear in mind that policy appropriates perfectly common and valid English for its own uses, and this is very easy to stumble over when writing proposals. I for one, have a history of stumbling over it multiple times in the past, and I expect to continue to do so until policy is fixed to use uppercased normative words or something like that. Well, If this proposal was in plain text, not a properly formed patch against current policy, and thus meant to be interpreted in the context of the policy document, perhaps that would have been clearer. manoj -- One good reason why computers can do more work than people is that they never have to stop and answer the phone. 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
Re: setuid/setgid binaries contained in the Debian repository.
Manoj Srivastava wrote: I note that later discussion tried to paint this whole process as getting people involved in auditing code, and not a mandatory requirement (ie, if you do not get a consensus then your package is buggy) that was in the original proposal. Fundamentally you make a wrong assumption. If policy requires that developers MUST hop on one leg while uploading packages, and someone catches me sitting down during a long upload, a bug on my package will do nothing to correct that, and will be fixed by a bit-identical upload made in the privacy of my own home (while lying down, probably). Policy cannot mandate developer behavior outside the strings of bits we're allowed to put into Debian. I have a full log of this email conversation, as indeed do the list archives, so just go back and lok the whole thread up. It'd be great if you'd use your archive to read the thread and motivatons that led up to the draft proposal before you try to falsly accuse us as you do in the first paragraph I've quoted. Well, If this proposal was in plain text, not a properly formed patch against current policy, and thus meant to be interpreted in the context of the policy document, perhaps that would have been clearer. It was clearly marked as a draft proposal, and not a formal policy proposal. And frankly, the thread was quite congenial and productive until you came along. -- see shy jo pgpY92rKVwpoj.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Sun, 3 Aug 2003 22:30:52 -0400, Joey Hess [EMAIL PROTECTED] said: Manoj Srivastava wrote: I note that later discussion tried to paint this whole process as getting people involved in auditing code, and not a mandatory requirement (ie, if you do not get a consensus then your package is buggy) that was in the original proposal. Fundamentally you make a wrong assumption. If policy requires that developers MUST hop on one leg while uploading packages, and someone catches me sitting down during a long upload, a bug on my package will do nothing to correct that, and will be fixed by a bit-identical upload made in the privacy of my own home (while lying down, probably). Policy cannot mandate developer behavior outside the strings of bits we're allowed to put into Debian. Policy can make it so that packages are not accepted into Debian unless you hop through certain hoops. Like making sure the upload has a signature. Or that it has an entry in the override file. I can easily code an entry for katie and friends that takes a new package, and marks up the ones with setgid bits set -- and the ftp maintainers do not create override entries until they see a consensus develop, or the security team says ok. For gods sake, come up with some more intelligent arguments for your point of view. I have a full log of this email conversation, as indeed do the list archives, so just go back and lok the whole thread up. It'd be great if you'd use your archive to read the thread and motivatons that led up to the draft proposal before you try to falsly accuse us as you do in the first paragraph I've quoted. Are you saying that the review was not discussed as a gating mechanism? If that is the case, then I admit I, for one, was fooled. Message-ID: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] All set[ug]id setups should be reviewed before they go into the archive. Sounds like this has more teeth than hopping on one leg. And, unlike things like how many legs one is standing on. Well, If this proposal was in plain text, not a properly formed patch against current policy, and thus meant to be interpreted in the context of the policy document, perhaps that would have been clearer. It was clearly marked as a draft proposal, and not a formal policy proposal. And frankly, the thread was quite congenial and productive until you came along. Sure. As long as there is no dissent, or disagreement, everything is cosy and hunky dory. The first sign of disagreement, though, the whole congeniality things frays apart. The idea is not to only be nice and freindly to yes men, but also to be able to discuss rationally with people who do not share your view, without bringing in ridiculously insulting strawmen like hopping on one foot. manoj -- Immigration is the sincerest form of flattery. Jack Paar 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
Re: setuid/setgid binaries contained in the Debian repository.
Manoj Srivastava wrote: Policy can make it so that packages are not accepted into Debian unless you hop through certain hoops. Like making sure the upload has a signature. Or that it has an entry in the override file. No, those have nothing to do with policy and are implemented solely at the ftp master's discretion. If I had intended to gate setuid binaries from debian, I would have posted to debian-cabal, not debian-devel. Are you saying that the review was not discussed as a gating mechanism? If that is the case, then I admit I, for one, was fooled. Message-ID: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] All set[ug]id setups should be reviewed before they go into the archive. Manoj, you have misquoted Matt here. After the word archive, he put not a period, but the rest of his sentence. If you read the whole thing: I absolutely support this idea. All set[ug]id setups should be reviewed before they go in the archive, and I volunteer to do the review (though I hope that others will help). Does this need a proposal to go into policy with the same force as the existing pre-depends verbiage? Matt is here, I belive, expressing a heartfelt opinion that it would be good for us to find security problems before they become *our* security problems. Moreover he's volenteering to do work. If his use of should was not satisfactory, well, he was not making a formal policy poposal either. I'm willing to cut people who do work a lot more slack than those who impede it. The idea is not to only be nice and freindly to yes men, but also to be able to discuss rationally with people who do not share your view, without bringing in ridiculously insulting strawmen like hopping on one foot. One of my rules of thumb is to stop replying to threads when my opponents resort to terms they learned in debating class, or to misquoting, since nothing good ever comes of it. Bye. -- see shy jo pgprO8o86eZrS.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 21:12:10 -0400, Joey Hess [EMAIL PROTECTED] said: Manoj Srivastava wrote: This seems like a good practice kind of recommendation, not an requirement, and as such, may be better suited to be included in developers reference rather than policy, don't you think? I agree that policy can't force developers to do that, but policy is already full of such recommendatons: 1. You should not specify a `Pre-Depends' entry for a package before this has been discussed on the `debian-devel' mailing list and a consensus about doing that has been reached. Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. 2. You must not tag any packages `essential' before this has been discussed on the `debian-devel' mailing list and a consensus about doing that has been reached. Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. 3. You should not tag any packages as belonging to a task before this has been discussed on the _debian-devel_ mailing list and a consensus about doing that has been reached. Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. 4. This will use a default sequence number of 20. If it does not matter when or in which order the `init.d' script is run, use this default. If it does, then you should talk to the maintainer of the `sysvinit' package or post to `debian-devel', and they will help you choose a number. Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. 5. If this case happens, one of the programs must be renamed. The maintainers should report this to the `debian-devel' mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, _both_ programs must be renamed. Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. 6. (on perms and users) 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. OK, the first issue of this kind. 7. In this case you should choose an appropriate user or group name, discussing this on `debian-devel' and checking with the `base-passwd' maintainer that it is unique and that they do not wish you to use a statically allocated id instead. Hmm. I am not sure if program behaviour need be changed much with user name/uid changes, but I guess there could be exceptions. 8. It is often worthwhile contacting such authors diplomatically to ask them to modify their license terms. However, this can be a politically difficult thing to do and you should ask for advice on the `debian-legal' mailing list first, as explained below. Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. 9. When in doubt about a copyright, send mail to debian-legal@lists.debian.org. Be prepared to provide us with the copyright statement. Packaging informatoin, not program behaviour affected by this. Packaging details are determined by developers, and can be easily changed. Do you plan to move all these to the developer's reference? It would bloat the developer's reference with references to specific sections of policy, and leave the policy full of holes with no recommendations as to a good course of action or even a mention that a given action is potentially hazardous. You are now talking about putting things into policy that require maintainerrs to change program behaviour to attain similar functionality and features; and all the examples you quote are about packaging details that are under our control completely. Apples and oranges, really. manoj -- It says he made us all to be just like him. So if we're dumb, then god is dumb, and maybe even a little ugly on the side. Frank Zappa 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
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 23:57:04 +0200, Bernd Eckenfels [EMAIL PROTECTED] said: On Fri, Aug 01, 2003 at 03:58:13PM -0500, Manoj Srivastava wrote: Hmm. Are you willing then to help modify each game to allow this to happen? Some changes are quite extensive. Hmm.. I am sure the maintainers of the affected packages will ask for help. Fine then. I'll have problems converting angband. manoj -- Television -- the longest amateur night in history. Robert Carson 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
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 09:16:25PM -0400, Joey Hess wrote: Only because Steve Kemp is doing some good work on auditing our games. I suspect he would have just as much luck finding security holes in some other areas. I've mostly covered the games now, there's not too many left that I want to have a look at. Next it's editors - I can't believe I found a setuid(0) one! Yes, but I think the eyes should concentrate on non sgid-games first. Because this might be a realy BIG junk of UGLYNESS one will find there :) I've found a lot of problems in non-setgid programs too, but those reports don't often get as much attention - and to be honest they're usually triggered by situations a normal user wouldn't ever trigger. So, sure they're important, but they're not _as_ important. I understand that if you want to help with the auditing effort, information is here: http://www.steve.org.uk/Debian/ Yes assistence would be great; I've not coordinated anything so at the moment it's a bit arbitary pick a package, and have a look at it. I'll post a list of the packages that I've eximined shortly to avoid duplication. Steve --- www.steve.org.uk pgpvH4PiaombR.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 11:39:24PM -0500, Manoj Srivastava wrote: You are now talking about putting things into policy that require maintainerrs to change program behaviour to attain similar functionality and features; and all the examples you quote are about packaging details that are under our control completely. No, we are talking about recommending that developers discuss with other developers before making a change to their package which is 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? -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 10:24:46PM +0200, Bernd Eckenfels wrote: DSA-360: no (daemon) DSA-359: yes (uid root: hardware access) DSA-358: no (kernel) DSA-357: no (daemon) DSA-356: yes (gid games) DSA-355: no (web css) DSA-354: yes (gid games) DSA-353: no (daemon, temp file) DSA-352: no (user, temp file) DSA-351: no (web css) DSA-350: yes (gid games) DSA-349: no (daemon) DSA-348: yes (system root tool exploit) ... Looking at this statistic, it is clearly visible that most of the exploits are game related, in fact only one system tool and one hardware accessing 'game' would allow suid root exploits, all others are sgid games. This only means that we have a lot of games which are setgid and give no thought to security, and that Steve Kemp has recently been rather prolifically pointing this out (and fixing the bugs). There are far too many setuid programs in Debian, especially setuid root. Many of them are in obscure packages like leksbot or atari800, and so go unnoticed for long periods of time, but anyone who unwittingly installs one of these packages has severely compromised the security of their system. Tools like dh_fixperms go a long way, by preventing maintainers from getting caught by poor upstream decisions, but I think it is critical that we have a review process before maintainers intentionally add privileged programs to their packages. And some of the suid root stuff, like hardware acces might even require debian to switch to some more sensible kernel setups. svgalib is a frequent offender in this department, and at this point I think that there are enough good alternatives to svgalib (which do not require root access) that we should deprecate it as a reason for making programs setuid entirely. +p + Since setuid and setgid programs are often a security rick, + you should not add any new setuid or setgid programs to + the distribution before this has been discussed on the + emdebian-security/em mailing list and a consensus about + doing that has been reached. +/p Do we want to make an sgui games exception here? I do not think so; gid games vulnerabilities represent a legitimate security exposure. Consider that many games are careless when it comes to handling data files they have written with these privileges. If a user can write to those files, they can exploit bugs in the game in order to gain the privileges of other users who run the game. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, 2 Aug 2003 13:09:09 -0400, Matt Zimmerman [EMAIL PROTECTED] said: On Fri, Aug 01, 2003 at 11:39:24PM -0500, Manoj Srivastava wrote: You are now talking about putting things into policy that require maintainerrs to change program behaviour to attain similar functionality and features; and all the examples you quote are about packaging details that are under our control completely. 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? 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. Making the dir world writable is not a solution, and indeed, is worse for security. manoj -- Ever heard of .cshrc? That's a city in Bosnia. Right? Discussion in comp.os.linux.misc on the intuitiveness of commands 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
Re: setuid/setgid binaries contained in the Debian repository.
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). 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. Often, I believe that the discussion will determine whether or not it truly depends on being setid. 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. 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. 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 YOU APPEAR TO BE IMPLYING THAT I AM PROPOSING THAT: - Programs be rendered unusable by changing file permissions - Directories be made world-writable Absolutely none of the statements listed under the heading YOU APPEAR TO BE IMPLYING THAT I AM PROPOSING THAT are true. The statement listed under the heading I AM PROPOSING THAT is true. I hope this helps to avoid any further confusion. 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. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
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
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, Aug 02, 2003 at 02:22:27PM -0500, Manoj Srivastava wrote: 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. This is trivial, and should be documented even in the man page. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
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 [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
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, 2 Aug 2003 22:44:24 +0200, Bernd Eckenfels [EMAIL PROTECTED] said: On Sat, Aug 02, 2003 at 02:22:27PM -0500, Manoj Srivastava wrote: 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. This is trivial, and should be documented even in the man page. It is? OK, I am telling you /usr/bin/bar program in package foo really needs to be sgid. I'll document it in bar.6. Is this the end of discussion? Or are we going to really need to look at the code to see if the setgidness can be worked around? manoj -- On the Internet, no one knows you're using Windows NT (Submitted by Ramiro Estrugo, [EMAIL PROTECTED]) 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
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, Aug 02, 2003 at 05:09:56PM -0500, Manoj Srivastava wrote: It is? OK, I am telling you /usr/bin/bar program in package foo really needs to be sgid. I'll document it in bar.6. Is this the end of discussion? Or are we going to really need to look at the code to see if the setgidness can be worked around? It is the minimum I would expect from a good package, of course it can be done much better. Personally I do not care much about the games, because I expect them to be unsecure and simply do not install them on important servers with multiple users. However I can understand admins who want to maintain a friendly user environemnt, and we should serve them by allowing chmod g-s /usr/games/*. BTW: anband is playable without sgid, but since I do not manage to get past level 1 i am nor sure what kind of implications this has :) Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, 2 Aug 2003 16:55:12 -0400, Matt Zimmerman [EMAIL PROTECTED] 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 [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.
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
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, Aug 02, 2003 at 05:38:41PM -0500, Manoj Srivastava wrote: On Sat, 2 Aug 2003 16:55:12 -0400, Matt Zimmerman [EMAIL PROTECTED] said: 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. Perhaps the language should be adjusted a bit from Joey's original. It was not meant to serve as a roadblock but to encourage discussion. Though, even with the language ...a consensus [...] has been reached, the important part is you should meaning that this is a recommendation. 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. Earlier in this thread, Steve Kemp and I volunteered to be two of the people who will be reviewing these issues. I would assume that there are others reading debian-security who will have insight as well, but two is more than enough to do some good. 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? [...] I have brought /usr/bin/bar up for discussion now. I am anxious to see how it can be improved by this discussion. I would look at the code in that situation, of course. Perhaps then it would turn out that the upstream author never intended for this program to run setid (or had no knowledge of basic security practices), and baz happened to be group shadow, and you were making a poor decision. But the more common scenarios are things like I think this program needs to be setuid in order to read and write some file or I want to make program setuid [when it was not designed to operate setid] which are often incorrect. If your primary concern is about the traditional setgid-games configuration, can you suggest a modification to the text which would address that concern? Bear in mind, the risks involved in setgid-games vulnerabilities are real, and go beyond forging high scores and saved games, and I believe that a certain minimum level of discretion should be applied, as with any setid program. Anyway, if it is all that simple and sensible, Why do we need policy to tell us to do normal, sensible, security related things? Many maintainers are simply not aware of good security practices. This is not because they are stupid or incompetent; it is because the issues are often subtle and they have never learned good security habits. Many programmers can look at a line of code like strcpy(foo, bar) without flinching, while it might make a security expert's skin crawl. We do not require maintainers to have this kind of expertise, so why would you expect it of them? 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. This statement has very little meaning from you. 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. To clarify yet again, the statement in question was File permissions and program privileges are clearly a packaging matter. I never said it was just or merely a packaging issue, while you have tried to put both of those words in my mouth. Of course these issues have an effect on program design and implementation; so does nearly every other aspect of packaging. But it remains true that file permissions and program privileges are a matter of
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, 2 Aug 2003 20:48:26 -0400, Matt Zimmerman [EMAIL PROTECTED] said:
That's nice. angband links with every library on the planet,
including X11. This should be easy.
[...about 2 minutes later...]
Even easier than I thought.
mizar:[...ity/angband/angband-291/src] tail +81 main.c | head -30
static void init_stuff(void) {
char path[1024];
if defined(AMIGA) || defined(VM)
/* Hack -- prepare path */ strcpy(path, Angband:);
else /* AMIGA / VM */
cptr tail;
/* Get the environment variable */ tail =
getenv(ANGBAND_PATH);
/* Use the angband_path, or a default */ strcpy(path, tail ?
tail : DEFAULT_PATH);
/* Hack -- Add a path separator (only if needed) */ if
(!suffix(path, PATH_SEP)) strcat(path, PATH_SEP);
endif /* AMIGA / VM */
/* Initialize */ init_file_paths(path);
mizar:[...ity/angband/angband-291/src] ANGBAND_PATH=`perl -e 'print
A x 1050'` gdb /usr/games/angband GNU gdb
5.3.90_2003-06-29-cvs-debian Copyright 2003 Free Software
Foundation, Inc. GDB is free software, covered by the GNU General
Public License, and you are welcome to change it and/or distribute
copies of it under certain conditions. Type show copying to see
the conditions. There is absolutely no warranty for GDB. Type
show warranty for details. This GDB was configured as
i386-linux...(no debugging symbols found)... (gdb) r Starting
program: /usr/games/angband (no debugging symbols found)...(no
debugging symbols found)... (no debugging symbols found)...(no
debugging symbols found)... (no debugging symbols found)...(no
debugging symbols found)... (no debugging symbols found)...(no
debugging symbols found)... (no debugging symbols found)...(no
debugging symbols found)... (no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault. 0x41414141 in
?? ()
I'd be happy if you would check your package for trivial security
exploits before uploading it to Debian.
Why do we need policy to tell us to do what you suggest are good,
common sense things?
As the maintainer of a package containing a setgid program with a
glaring security hole, perhaps you can tell me.
Heh. You should look at what is in the current version:
==
#ifndef FIXED_PATHS
/* Get the environment variable */
tail = getenv(ANGBAND_PATH);
#endif /* FIXED_PATHS */
/* Use the angband_path, or a default */
my_strcpy(path, tail ? tail : DEFAULT_PATH, sizeof(path));
/* Make sure it's terminated */
path[511] = '\0';
/* Hack -- Add a path separator (only if needed) */
if (!suffix(path, PATH_SEP)) my_strcat(path, PATH_SEP, sizeof(path));
#endif /* AMIGA / VM */
/* Initialize */
init_file_paths(path);
--
/*
* The my_strcpy() function copies up to 'bufsize'-1 characters from 'src'
* to 'buf' and NUL-terminates the result. The 'buf' and 'src' strings may
* not overlap.
*
* my_strcpy() returns strlen(src). This makes checking for truncation
* easy. Example: if (my_strcpy(buf, src, sizeof(buf)) = sizeof(buf)) ...;
*
* This function should be equivalent to the strlcpy() function in BSD.
*/
size_t my_strcpy(char *buf, const char *src, size_t bufsize)
{
size_t len = strlen(src);
size_t ret = len;
/* Paranoia */
if (bufsize == 0) return ret;
/* Truncate */
if (len = bufsize) len = bufsize - 1;
/* Copy the string and terminate it */
(void)memcpy(buf, src, len);
buf[len] = '\0';
/* Return strlen(src) */
return ret;
}
==
Superficial audits are probably worse rthan none; they tend to
raise false senses of security.
manoj
--
Nature gave man two ends--one to sit on and one to think with. Ever
since then man's success or failure has been dependent on the one he
used most. George R. Kirkpatrick
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
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 13:46:48 -0400, Joey Hess [EMAIL PROTECTED] wrote: --- policy.sgml.orig 2003-08-01 13:40:51.0 -0400 +++ policy.sgml 2003-08-01 13:45:24.0 -0400 @@ -7104,6 +7104,14 @@ execute them. /p +p + Since setuid and setgid programs are often a security rick, + you should not add any new setuid or setgid programs to + the distribution before this has been discussed on the + emdebian-security/em mailing list and a consensus about + doing that has been reached. +/p + p It is possible to arrange that the system administrator can reconfigure the package to correspond to their local I object. My interpretation of this paragraph is if there were not nethack in Debian, we would not need it unless you remove the score file, the bone file, the player ghost and whatever from it or you implement them securely without any setid. I don't care if you mandate a prior peer view _request_ (not prior approval) when ITPing a setid program, but if no one says anything about it for some weeks, why can't I upload that program? After all, I maintain the package. Pre-Depends or something that is already in the Policy is more or less about package relationship, but setid is not. -- Oohara Yuuma [EMAIL PROTECTED] Debian developer PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695 Er, let's get into all the messes of the parliament. --- shinichiro.h, diary 2003/3/24 parliamentary bullet-dodging system
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, Aug 02, 2003 at 08:14:15PM -0500, Manoj Srivastava wrote: Heh. You should look at what is in the current version: Is that what you would say to the users who have angband installed on Woody? I do not think this is something to laugh about. Superficial audits are probably worse rthan none; they tend to raise false senses of security. Only if their results are interpreted incorrectly. A superficial audit is enough to say this program cannot be trusted to be setid until it has received a more thorough audit. If no one is willing or able to perform such an audit, the program should not be distributed setid. This is the kind of result that I hope would be achieved by recommending discussion before new setid programs are added to the distribution. If we had the resources to thoroughly audit all such programs before distributing them, that would be better, but as yet we do not. However, having an established channel for this kind of review makes it easier for interested parties to perform some amount of auditing. Of course, even thorough auditing cannot provide security guarantees, it can only find new bugs. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, 2 Aug 2003 20:48:26 -0400, Matt Zimmerman [EMAIL PROTECTED] said: This, sir, is a lie. This statement has very little meaning from you. Then I think this discussion has reached the end of its useful life. 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. To clarify yet again, the statement in question was File permissions and program privileges are clearly a packaging matter. I never said it was just or merely a packaging issue, while you have tried to put both of those words in my mouth. Of course these issues have an effect on program design and implementation; so does nearly every other aspect of packaging. But it remains true that file permissions and program privileges are a matter of Debian policy, and a significant part of the packaging process for nontrivial programs. You had no excuse for accusing me of being disingenuous, and you have yet to retract this accusation. Wrong again. Here is the context, that you are eliding: You are now talking about putting things into policy that require maintainerrs to change program behaviour to attain similar functionality and features; and all the examples you quote are about packaging details that are under our control completely. I was concerned that making programs not setgid is not a matter of adding a chown line in the rules file; that it needed perhaps a deeper understanding and modification of the code; and that this proposal differed from all other examples quoted. With this background, you come up with File permissions and program privileges are clearly a packaging matter. I stand by what I said. Earlier in this thread, Steve Kemp and I volunteered to be two of the people who will be reviewing these issues. I would assume that there are others reading debian-security who will have insight as well, but two is more than enough to do some good. Given the last review of a setgid program, I wonder if two people are enough. The mistake was simple, human, and undesrtandable, but the review does not in fact talk about any flaws in the current version of angband (tome does need to be so changed); and this kind of error would undermine the process -- especially if the results are couched in terms like those below: Why do we need policy to tell us to do what you suggest are good, common sense things? As the maintainer of a package containing a setgid program with a glaring security hole, perhaps you can tell me. Perhaps more people would reduce the tensions and permit a more, umm, civilized, and correct, audit to be performed? manoj -- We have met the enemy and he is us Walt Kelly (in POGO) 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
Re: setuid/setgid binaries contained in the Debian repository.
* Steve Kemp [...] | I'm loath to ask the user if it should be setgid in the installer | because that's just needless distraction, but perhaps some global | 'setgidnes' setting could be stored in /etc/games? [...] what's wrong with a low-priority debconf question with a sane default? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote: what's wrong with a low-priority debconf question with a sane default? Absolutely nothing at all, but it's a slippery slope, and I thought we were tending towards less interactivity in installations? Steve --
Re: setuid/setgid binaries contained in the Debian repository.
On Thu, 31 Jul 2003 17:30:11 +0300, Richard Braakman wrote: On Thu, Jul 31, 2003 at 01:17:01PM +0100, Steve Kemp wrote: http://www.steve.org.uk/cgi-bin/debian/index.cgi If you're just scanning for binaries with s bits set, then you'll probably miss all the ones that use whatever that tool was (suidmanager?) that was used by some packages before we had dpkg-statoverride. As well as the ones using dpkg-statoverride in their postinsts now. -- Micha Politowski -- [EMAIL PROTECTED] Warning: this is a memetically modified message pgpltuDWMkZ1q.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
* Steve Kemp | On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote: | | what's wrong with a low-priority debconf question with a sane default? | | Absolutely nothing at all, but it's a slippery slope, and I thought | we were tending towards less interactivity in installations? which is why I said «low priority»: 'critical' only prompts you if the system might break. Pick it if you are a newbie, or in a hurry. 'high' is for rather important questions 'medium' is for normal questions 'low' is for control freaks who want to see everything If you select low, you will have to drink off the fire hose. Having low-priority questionsis good, since it makes it easy to make customized installs with preloaded answers. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 10:08:17AM +0200, Micha? Politowski wrote: On Thu, 31 Jul 2003 17:30:11 +0300, Richard Braakman wrote: On Thu, Jul 31, 2003 at 01:17:01PM +0100, Steve Kemp wrote: http://www.steve.org.uk/cgi-bin/debian/index.cgi If you're just scanning for binaries with s bits set, then you'll probably miss all the ones that use whatever that tool was (suidmanager?) that was used by some packages before we had dpkg-statoverride. As well as the ones using dpkg-statoverride in their postinsts now. From my investigations, I thought that the intended use of dpkg-statoverride was by the local administrator, modifying the default suid/sgid and ownership of the file as set in the package tarball. - Matt
Re: setuid/setgid binaries contained in the Debian repository.
Joey Hess [EMAIL PROTECTED] wrote:
I also think it would be a good idea for policy to require all
setuid/gid bit grants to go through this or another list for peer
review, much as pre-depends are supposed to.
How about creating a new group for each game?
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 19:19:10 +1000, Matthew Palmer wrote: [...] From my investigations, I thought that the intended use of dpkg-statoverride was by the local administrator, modifying the default suid/sgid and ownership of the file as set in the package tarball. This is also my understanding. Still, some packages do use it for better or worse reasons. One example I've just found in uml-utilities.postinst: if ! getent group uml-net /dev/null; then addgroup --quiet --system uml-net fi if ! dpkg-statoverride --list /usr/lib/uml/uml_net /dev/null; then dpkg-statoverride --update --add root uml-net 04750 \ /usr/lib/uml/uml_net fi -- Micha Politowski -- [EMAIL PROTECTED] Warning: this is a memetically modified message pgpBNKpOPbVPj.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
Herbert Xu wrote: Joey Hess [EMAIL PROTECTED] wrote: I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. How about creating a new group for each game? Umm... With hundreds, possibly thousands (in the future anyway) of games, is this really what you want to do? -- Keith
Re: setuid/setgid binaries contained in the Debian repository.
On Thu, Jul 31, 2003 at 12:55:28PM -0400, Joey Hess wrote: I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. I absolutely support this idea. All set[ug]id setups should be reviewed before they go in the archive, and I volunteer to do the review (though I hope that others will help). Does this need a proposal to go into policy with the same force as the existing pre-depends verbiage? -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Thu, Jul 31, 2003 at 06:37:53PM +0100, Steve Kemp wrote: On Thu, Jul 31, 2003 at 12:55:28PM -0400, Joey Hess wrote: I'd like to see us move all of our setgid games (except, perhaps, nethack) away from using global score files by default. I think that should be a good option, but I can see several games that might suffer by it. I'm loath to ask the user if it should be setgid in the installer because that's just needless distraction, but perhaps some global 'setgidnes' setting could be stored in /etc/games? Personally, I would lean more towards having a setgid helper which writes to the game's score file. It is possible to audit such helpers completely in a short amount of time, and I feel that it would be far better to open ourselves up to letting users forge their own high scores than to the current exposures which are possible through group games. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote: what's wrong with a low-priority debconf question with a sane default? As long as the sane default is the safe default, which is not to be setgid. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 08:45:16PM +1000, Herbert Xu wrote: Joey Hess [EMAIL PROTECTED] wrote: I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. How about creating a new group for each game? This is only somewhat better, from a security perspective, than sharing a group, depending on how many games are installed on the system. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 11:18:53AM -0400, Matt Zimmerman wrote: I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. I absolutely support this idea. All set[ug]id setups should be reviewed before they go in the archive, and I volunteer to do the review (though I hope that others will help). Does this need a proposal to go into policy with the same force as the existing pre-depends verbiage? I would support such a change too, and would volunteer to assist if there was need for it. Steve -- pgpVrvHIYtBXb.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
* Matt Zimmerman ([EMAIL PROTECTED]) wrote: On Thu, Jul 31, 2003 at 12:55:28PM -0400, Joey Hess wrote: I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. I absolutely support this idea. All set[ug]id setups should be reviewed before they go in the archive, and I volunteer to do the review (though I hope that others will help). Does this need a proposal to go into policy with the same force as the existing pre-depends verbiage? It probably should. I'd be willing to say we might want a seperate list for this too. I'm willing to help with the review but I tend to skim d-d.. Stephen pgpYXXeHWnI5U.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 11:26:57AM -0400, Stephen Frost wrote: * Matt Zimmerman ([EMAIL PROTECTED]) wrote: I absolutely support this idea. All set[ug]id setups should be reviewed before they go in the archive, and I volunteer to do the review (though I hope that others will help). Does this need a proposal to go into policy with the same force as the existing pre-depends verbiage? It probably should. I'd be willing to say we might want a seperate list for this too. I'm willing to help with the review but I tend to skim d-d.. I think debian-security would be fine, maybe with a special Subject tag. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 11:34:11AM +0200, Tollef Fog Heen wrote: * Steve Kemp | On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote: | | what's wrong with a low-priority debconf question with a sane default? | | Absolutely nothing at all, but it's a slippery slope, and I thought | we were tending towards less interactivity in installations? which is why I said «low priority»: 'critical' only prompts you if the system might break. Pick it if you are a newbie, or in a hurry. 'high' is for rather important questions 'medium' is for normal questions 'low' is for control freaks who want to see everything If you select low, you will have to drink off the fire hose. Having low-priority questionsis good, since it makes it easy to make customized installs with preloaded answers. The only question I would have about it is that every potentially-sgid game package would need to share the question (so that it only got asked once, but was available whenever needed) - organizing that could be a bit tricky, I would think. Certainly I think it would be one of the more reasonable uses of shared debconf stuff - one question, low priority, a sane default of not being sgid, and assuming packages used something proper (er, dpkg-statoverride?) to register the sgid bit, it doesn't matter if you blow away the answer cache - you can look at the existing state and find out what you need to know (or, presumably, override it). -- Joel Baker [EMAIL PROTECTED] pgpHUUfcNpVft.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Thu, Jul 31, 2003 at 05:33:23PM +0100, Steve Kemp wrote: There's probably a lot to be said for building a chroot installation and installing each package in turn; but I don't have the time for that at the moment. I have some basic tools for doing this kind of thing using UML's copy-on-write block devices, so it is relatively efficient. This is one of the things that I plan to do with it once it is ready for large-scale projects. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
Matt Zimmerman wrote: On Fri, Aug 01, 2003 at 11:26:57AM -0400, Stephen Frost wrote: * Matt Zimmerman ([EMAIL PROTECTED]) wrote: I absolutely support this idea. All set[ug]id setups should be reviewed before they go in the archive, and I volunteer to do the review (though I hope that others will help). Does this need a proposal to go into policy with the same force as the existing pre-depends verbiage? It probably should. I'd be willing to say we might want a seperate list for this too. I'm willing to help with the review but I tend to skim d-d.. I think debian-security would be fine, maybe with a special Subject tag. Here's a draft policy proposal. If this looks ok I'll submit it to the policy group. Proposal: [DRAFT] require peer review for setuid and setgid program introduction Setuid and setgid programs are one of the main causes of security holes and DSA's in Debian. Often these holes can be spotted easily with a simple review. Sometimes setuid/gid programs can be modified in fairly simple ways to not need these dangerous permissions at all. A few well-trained eyes looking over a package before it goes into the distribution and becomes a security risk can make all the difference. So, I propose that any new setuid or setgid programs should be reviewed by a team of interested people before being put into the distribution. In discussions on debian-devel, we agreed this was a good idea, and that debian-security is the appropriate list for these reviews. The reviewers will be whoever is interested, which currently includes at least one member of the security team, and one of our most prolific security auditors. Note the paralell with the existing requirement that essential packages be discussed on debian-devel. --- policy.sgml.orig2003-08-01 13:40:51.0 -0400 +++ policy.sgml 2003-08-01 13:45:24.0 -0400 @@ -7104,6 +7104,14 @@ execute them. /p +p + Since setuid and setgid programs are often a security rick, + you should not add any new setuid or setgid programs to + the distribution before this has been discussed on the + emdebian-security/em mailing list and a consensus about + doing that has been reached. +/p + p It is possible to arrange that the system administrator can reconfigure the package to correspond to their local -- see shy jo pgpsKaYcBNHRc.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
Matt Zimmerman wrote: Personally, I would lean more towards having a setgid helper which writes to the game's score file. It is possible to audit such helpers completely in a short amount of time, and I feel that it would be far better to open ourselves up to letting users forge their own high scores than to the current exposures which are possible through group games. I think you can set it up so users cannot forge high scores by just running such a helper. Make the helper sgid scorewriter, and make the games setgid scoresetter (these names could be better). Then the helper would refuse to write any scores unless its real GID is scoresetter. -- see shy jo pgplRuxCwkTHX.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 01:56:50PM -0400, Joey Hess wrote: I think you can set it up so users cannot forge high scores by just running such a helper. Make the helper sgid scorewriter, and make the games setgid scoresetter (these names could be better). Then the helper would refuse to write any scores unless its real GID is scoresetter. I considered something like this, but I dismissed it as overcomplicated for the problem (of forging local high scores). I'd rather decrease the overall number of privileged programs than reorganize into a larger number of privilege groups. With fewer and fewer users per system these days, there isn't usually any glory in this kind of high score anyway, and only client/server games which are mediated by a neutral server can usefully provide this kind of scorekeeping. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 01:46:48PM -0400, Joey Hess wrote: Here's a draft policy proposal. If this looks ok I'll submit it to the policy group. Thanks for doing this. It looks fine, with the exception of a small typo: + Since setuid and setgid programs are often a security rick, ^ risk If we could come up with a standard way of setting these permissions, to avoid the kind of messing around in the postinst that we do now, it would be trivial to add lintian/linda warnings for this, to encourage maintainers to discuss the situation before uploading. doogie, asuffield and I discussed this on IRC recently. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 02:15:26PM -0400, Matt Zimmerman wrote: it would be trivial to add lintian/linda warnings for this, There's already a warning for set[ug]id in Lintian. -- 2. That which causes joy or happiness.
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 08:20:40PM +0200, Josip Rodin wrote: On Fri, Aug 01, 2003 at 02:15:26PM -0400, Matt Zimmerman wrote: it would be trivial to add lintian/linda warnings for this, There's already a warning for set[ug]id in Lintian. Ah, ok. But the point was that it will miss many cases. For example, I've never seen this warning in uml-utilities because it uses a dynamically-allocated gid and so must use chmod in postinst rather than setting permissions in the .deb. If this could be done at build time rather than at install time, the check would be perfect. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
* Joey Hess ([EMAIL PROTECTED]) wrote: --- policy.sgml.orig 2003-08-01 13:40:51.0 -0400 +++ policy.sgml 2003-08-01 13:45:24.0 -0400 @@ -7104,6 +7104,14 @@ execute them. /p +p + Since setuid and setgid programs are often a security rick, 'risk' might be a bit better. :) + you should not add any new setuid or setgid programs to + the distribution before this has been discussed on the until it has been discussed .. ? + emdebian-security/em mailing list and a consensus about + doing that has been reached. and a consensus reached which approves of the application and it's needs. ? Stephen pgp0zhMViopSR.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003, Matt Zimmerman wrote: On Fri, Aug 01, 2003 at 08:20:40PM +0200, Josip Rodin wrote: On Fri, Aug 01, 2003 at 02:15:26PM -0400, Matt Zimmerman wrote: it would be trivial to add lintian/linda warnings for this, There's already a warning for set[ug]id in Lintian. Ah, ok. But the point was that it will miss many cases. For example, I've never seen this warning in uml-utilities because it uses a dynamically-allocated gid and so must use chmod in postinst rather than setting permissions in the .deb. If this could be done at build time rather than at install time, the check would be perfect. Andrew Suffield and I have plans to get rid of dynamic user creation in postinst, and chmod +s as well. preinst will create the user(by calling adduser), then the setuid-ness in the deb can be applied. This invovles modifying dpkg-deb to read a list of permission overrides. See -policy.
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 11:22:17 -0400, Matt Zimmerman [EMAIL PROTECTED] said: On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote: what's wrong with a low-priority debconf question with a sane default? As long as the sane default is the safe default, which is not to be setgid. Only if the game still works -- some games keep not just score files, but saved games in the common area, and would not work as expected if they could not write to that area. manoj -- St. Patrick was a gentleman who through strategy and stealth drove all the snakes from Ireland. Here's a toasting to his health -- but not too many toastings lest you lose yourself and then forget the good St. Patrick and see all those snakes again. 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
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 13:46:48 -0400, Joey Hess [EMAIL PROTECTED] said: Here's a draft policy proposal. If this looks ok I'll submit it to the policy group. Proposal: [DRAFT] require peer review for setuid and setgid program introduction Setuid and setgid programs are one of the main causes of security holes and DSA's in Debian. Often these holes can be spotted easily with a simple review. Sometimes setuid/gid programs can be modified in fairly simple ways to not need these dangerous permissions at all. A few well-trained eyes looking over a package before it goes into the distribution and becomes a security risk can make all the difference. So, I propose that any new setuid or setgid programs should be reviewed by a team of interested people before being put into the distribution. In discussions on debian-devel, we agreed this was a good idea, and that debian-security is the appropriate list for these reviews. The reviewers will be whoever is interested, which currently includes at least one member of the security team, and one of our most prolific security auditors. Note the paralell with the existing requirement that essential packages be discussed on debian-devel. This seems like a good practice kind of recommendation, not an requirement, and as such, may be better suited to be included in developers reference rather than policy, don't you think? manoj -- The Bird of Time has but a little way to fly ... and the bird is on the wing. Omar Khayyam 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
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 02:15:50PM -0500, Manoj Srivastava wrote: Only if the game still works -- some games keep not just score files, but saved games in the common area, and would not work as expected if they could not write to that area. nethack is the only game which comes to mind which does this, and I think it should probably be changed to keep the saved game in the user's home directory. This was clearly done in order to try to prevent cheating, but again, these days the player has root anyway. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 16:01:03 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Fri, Aug 01, 2003 at 02:15:50PM -0500, Manoj Srivastava wrote: Only if the game still works -- some games keep not just score files, but saved games in the common area, and would not work as expected if they could not write to that area. nethack is the only game which comes to mind which does this, and I think it should probably be changed to keep the saved game in the user's home directory. This was clearly done in order to try to prevent cheating, but again, these days the player has root anyway. Hmm, that is not the only reason, and maybe not the real reason. What about bones piles? Doesn't nethack do this partially so that levels from dead games could be reused in future games? On a multi-user system, you get a better set of bones piles, because you have no idea of what killed the adventurer, and probably no idea of whether anything is worth picking up and risking the possibility of a curse. Jim Penny who has in past lives spent far too many hours playing nethack
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 01:46:48PM -0400, Joey Hess wrote: Setuid and setgid programs are one of the main causes of security holes and DSA's in Debian. Hmm DSA-360: no (daemon) DSA-359: yes (uid root: hardware access) DSA-358: no (kernel) DSA-357: no (daemon) DSA-356: yes (gid games) DSA-355: no (web css) DSA-354: yes (gid games) DSA-353: no (daemon, temp file) DSA-352: no (user, temp file) DSA-351: no (web css) DSA-350: yes (gid games) DSA-349: no (daemon) DSA-348: yes (system root tool exploit) ... Looking at this statistic, it is clearly visible that most of the exploits are game related, in fact only one system tool and one hardware accessing 'game' would allow suid root exploits, all others are sgid games. A few well-trained eyes looking over a package before it goes into the distribution and becomes a security risk can make all the difference. Yes, but I think the eyes should concentrate on non sgid-games first. Because this might be a realy BIG junk of UGLYNESS one will find there :) And some of the suid root stuff, like hardware acces might even require debian to switch to some more sensible kernel setups. +p + Since setuid and setgid programs are often a security rick, + you should not add any new setuid or setgid programs to + the distribution before this has been discussed on the + emdebian-security/em mailing list and a consensus about + doing that has been reached. +/p Do we want to make an sgui games exception here? Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 01:56:50PM -0400, Joey Hess wrote: I think you can set it up so users cannot forge high scores by just running such a helper. Make the helper sgid scorewriter, and make the games setgid scoresetter Umm... you invent a scorewriter for removing the sgui games bit? And then you add a sgid scoresetter? I dont think this makes mch sence. Although it is true, that sgid games exploit are a problem, because they can be used to invade other game playing users, personally I think it is much more important to look at the other suids first. BUT: i realy do think each game MUST offer the non sgid option. We could have a global question herer: Do you want to limit gaming experiencing on your system but therefore increase system security? If you answer yes here, no game will be installed sgid games, and therefore you do not have shared highscores. yes no Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 04:13:30PM -0400, Jim Penny wrote: On Fri, 1 Aug 2003 16:01:03 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: nethack is the only game which comes to mind which does this, and I think it should probably be changed to keep the saved game in the user's home directory. This was clearly done in order to try to prevent cheating, but again, these days the player has root anyway. Hmm, that is not the only reason, and maybe not the real reason. What about bones piles? Doesn't nethack do this partially so that levels from dead games could be reused in future games? On a multi-user system, you get a better set of bones piles, because you have no idea of what killed the adventurer, and probably no idea of whether anything is worth picking up and risking the possibility of a curse. Of course it is the real reason. Otherwise you get exactly the same feature with a world-writable directory. (and anyway, there exists 'hearse' now, though I haven't tried it) -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 22:31:16 +0200, Bernd Eckenfels [EMAIL PROTECTED] said:
BUT: i realy do think each game MUST offer the non sgid option. We
could have a global question herer:
Hmm. Are you willing then to help modify each game to allow
this to happen? Some changes are quite extensive.
manoj
--
Date: 23 Feb 90 19:01:21 GMT From: [EMAIL PROTECTED] (Randal
Schwartz) format STDOUT = @ @ @ @, $Just, $another,
$Perl, $hacker
. for(Just,another,Perl,hacker){eval\$$_=\$_;;};write;
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
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 16:01:03 -0400, Matt Zimmerman [EMAIL PROTECTED] said: On Fri, Aug 01, 2003 at 02:15:50PM -0500, Manoj Srivastava wrote: Only if the game still works -- some games keep not just score files, but saved games in the common area, and would not work as expected if they could not write to that area. nethack is the only game which comes to mind which does this, and I think it should probably be changed to keep the saved game in the user's home directory. This was clearly done in order to try to prevent cheating, but again, these days the player has root anyway. Well, if you are talking about packages in main, yes. But there are other games that follow policy that are also affected. manoj -- We cannot command nature except by obeying her. Sir Francis Bacon 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
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 03:58:13PM -0500, Manoj Srivastava wrote: Hmm. Are you willing then to help modify each game to allow this to happen? Some changes are quite extensive. Hmm.. I am sure the maintainers of the affected packages will ask for help. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: setuid/setgid binaries contained in the Debian repository.
I demand that Stephen Frost may or may not have written... [snip] and a consensus reached which approves of the application and it's needs. ? Almost: s/'// :-) -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | I don't ask for much, just untold riches... i Invalid device, 0:1
Re: setuid/setgid binaries contained in the Debian repository.
Matt Zimmerman [EMAIL PROTECTED] wrote:
nethack is the only game which comes to mind which does this, and I think it
should probably be changed to keep the saved game in the user's home
directory. This was clearly done in order to try to prevent cheating, but
again, these days the player has root anyway.
If the player has root then why are discussing the possibility of the
player cracking into the games group?
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: setuid/setgid binaries contained in the Debian repository.
Herbert Xu [EMAIL PROTECTED] writes: Matt Zimmerman [EMAIL PROTECTED] wrote: nethack is the only game which comes to mind which does this, and I think it should probably be changed to keep the saved game in the user's home directory. This was clearly done in order to try to prevent cheating, but again, these days the player has root anyway. If the player has root then why are discussing the possibility of the player cracking into the games group? The legitimate player has root and thus could cheat at the game. An illegitimate player is probably more interested in abusing the machine than cheating at nethack. -Brian
Re: setuid/setgid binaries contained in the Debian repository.
Manoj Srivastava wrote: This seems like a good practice kind of recommendation, not an requirement, and as such, may be better suited to be included in developers reference rather than policy, don't you think? I agree that policy can't force developers to do that, but policy is already full of such recommendatons: 1. You should not specify a `Pre-Depends' entry for a package before this has been discussed on the `debian-devel' mailing list and a consensus about doing that has been reached. 2. You must not tag any packages `essential' before this has been discussed on the `debian-devel' mailing list and a consensus about doing that has been reached. 3. You should not tag any packages as belonging to a task before this has been discussed on the _debian-devel_ mailing list and a consensus about doing that has been reached. 4. This will use a default sequence number of 20. If it does not matter when or in which order the `init.d' script is run, use this default. If it does, then you should talk to the maintainer of the `sysvinit' package or post to `debian-devel', and they will help you choose a number. 5. If this case happens, one of the programs must be renamed. The maintainers should report this to the `debian-devel' mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, _both_ programs must be renamed. 6. (on perms and users) 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. 7. In this case you should choose an appropriate user or group name, discussing this on `debian-devel' and checking with the `base-passwd' maintainer that it is unique and that they do not wish you to use a statically allocated id instead. 8. It is often worthwhile contacting such authors diplomatically to ask them to modify their license terms. However, this can be a politically difficult thing to do and you should ask for advice on the `debian-legal' mailing list first, as explained below. 9. When in doubt about a copyright, send mail to debian-legal@lists.debian.org. Be prepared to provide us with the copyright statement. Do you plan to move all these to the developer's reference? It would bloat the developer's reference with references to specific sections of policy, and leave the policy full of holes with no recommendations as to a good course of action or even a mention that a given action is potentially hazardous. I remember having this exact same discussion when #3 above was added to policy, BTW. -- see shy jo pgpAeBalyTOap.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
Bernd Eckenfels wrote: Looking at this statistic, it is clearly visible that most of the exploits are game related, Only because Steve Kemp is doing some good work on auditing our games. I suspect he would have just as much luck finding security holes in some other areas. Yes, but I think the eyes should concentrate on non sgid-games first. Because this might be a realy BIG junk of UGLYNESS one will find there :) I understand that if you want to help with the auditing effort, information is here: http://www.steve.org.uk/Debian/ +p + Since setuid and setgid programs are often a security rick, + you should not add any new setuid or setgid programs to + the distribution before this has been discussed on the + emdebian-security/em mailing list and a consensus about + doing that has been reached. +/p Do we want to make an sgui games exception here? No. -- see shy jo pgpXuNzo7W6KO.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
Bernd Eckenfels wrote: Umm... you invent a scorewriter for removing the sgui games bit? And then you add a sgid scoresetter? I dont think this makes mch sence. You need to learn some more about security then. Small, simple and well defined programs are often more secure than large monoliths that have to deal with arbitrary user input. Especially if the monolith was written in 1993 and the helper program in 2003. -- see shy jo pgpCuLoGzTIOC.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
I demand that Herbert Xu may or may not have written... Matt Zimmerman [EMAIL PROTECTED] wrote: nethack is the only game which comes to mind which does this, and I think it should probably be changed to keep the saved game in the user's home directory. This was clearly done in order to try to prevent cheating, but again, these days the player has root anyway. If the player has root then why are discussing the possibility of the player cracking into the games group? The machine could be running a network game server which is setgid games, though it could equally well have its own uid and be run setuid. -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | I don't ask for much, just untold riches... The basis of optimism is sheer terror.
Re: setuid/setgid binaries contained in the Debian repository.
On Sat, Aug 02, 2003 at 09:38:46AM +1000, Herbert Xu wrote: Matt Zimmerman [EMAIL PROTECTED] wrote: nethack is the only game which comes to mind which does this, and I think it should probably be changed to keep the saved game in the user's home directory. This was clearly done in order to try to prevent cheating, but again, these days the player has root anyway. If the player has root then why are discussing the possibility of the player cracking into the games group? Because in that case I was talking about high scores, and in the other case we are talking about one user compromising another. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 09:19:46PM -0400, Joey Hess wrote: Bernd Eckenfels wrote: Umm... you invent a scorewriter for removing the sgui games bit? And then you add a sgid scoresetter? I dont think this makes mch sence. You need to learn some more about security then. Small, simple and well defined programs are often more secure than large monoliths that have to deal with arbitrary user input. Especially if the monolith was written in 1993 and the helper program in 2003. Well, I am fine with that. Although the game is still sgid, which is not needed. Some other ways to check the programs integrity can be used. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: setuid/setgid binaries contained in the Debian repository.
A long time ago[1] I asked if there was a list of all the setuid/setgid binaries contained in the previous Debian stable release. As there still isn't such a list I've created one and placed it online with a simple search form. (This is the list that my recent spate of bug reporting has been based upon). http://www.steve.org.uk/cgi-bin/debian/index.cgi Steve -- www.steve.org.uk [1] http://lists.debian.org/debian-devel/2002/debian-devel-200211/msg02720.html pgpS8Jn3yG3EF.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Thu, Jul 31, 2003 at 01:17:01PM +0100, Steve Kemp wrote: http://www.steve.org.uk/cgi-bin/debian/index.cgi If you're just scanning for binaries with s bits set, then you'll probably miss all the ones that use whatever that tool was (suidmanager?) that was used by some packages before we had dpkg-statoverride. Richard Braakman
Re: setuid/setgid binaries contained in the Debian repository.
On Thu, Jul 31, 2003 at 05:30:11PM +0300, Richard Braakman wrote: If you're just scanning for binaries with s bits set, then you'll probably miss all the ones that use whatever that tool was (suidmanager?) that was used by some packages before we had dpkg-statoverride. Yes I know that I'm missing a few, but apart from the ones that get +suided in the Debian/rules files, or are handled via other means then I've got a more comprehensive list than I've seen anywhere else. There's probably a lot to be said for building a chroot installation and installing each package in turn; but I don't have the time for that at the moment. Steve -- www.steve.org.uk pgp9kxAnEFBVj.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
Steve Kemp wrote: A long time ago[1] I asked if there was a list of all the setuid/setgid binaries contained in the previous Debian stable release. As there still isn't such a list I've created one and placed it online with a simple search form. (This is the list that my recent spate of bug reporting has been based upon). http://www.steve.org.uk/cgi-bin/debian/index.cgi I'd like to see us move all of our setgid games (except, perhaps, nethack) away from using global score files by default. After several bad experiences with xbl (DSA-345, DSA-327)), I suggested to its author that it be changed to use a score file in the player's home directory. We ended up making it do that by default, but letting it use a global score file if it is locally made setgid since it's been pretty well audited by now. Anyway, the point is that most games need a global score file like I need a third ear -- maybe useful from time to time[1], but normally just one more thing to worry about. I plan to go through the rest of the games I maintain and make similar changes. I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. -- see shy jo [1] Multi-user game machines are not as common as they once were. pgpqovdo6S6Tu.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Thu, Jul 31, 2003 at 12:55:28PM -0400, Joey Hess wrote: I'd like to see us move all of our setgid games (except, perhaps, nethack) away from using global score files by default. I think that should be a good option, but I can see several games that might suffer by it. I'm loath to ask the user if it should be setgid in the installer because that's just needless distraction, but perhaps some global 'setgidnes' setting could be stored in /etc/games? I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. I was thinking of approaching that problem a different way. In the same way that apt-listchanges shows a packages changelog at install time, I could see a script 'apt-listsetuid' which would warn the admin at install time if any new setuid/setgid applications were being installed. (Optionally with the option to remove such bits on a global or per package basis). I've thought this several times, but never quite gotten around to writing the code - if there was any interest I would. Steve --- www.steve.org.uk pgpDp7LJFCK6J.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Thu, Jul 31, 2003 at 06:37:53PM +0100, Steve Kemp wrote: On Thu, Jul 31, 2003 at 12:55:28PM -0400, Joey Hess wrote: I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. I was thinking of approaching that problem a different way. In the same way that apt-listchanges shows a packages changelog at install time, I could see a script 'apt-listsetuid' which would warn the admin at install time if any new setuid/setgid applications were being installed. I use checksecurity for this; it runs from cron (daily by default) and notifies me whenever there is a change in the list of setuid and setgid programs on the system. -- - mdz
Re: setuid/setgid binaries contained in the Debian repository.
Steve Kemp wrote: On Thu, Jul 31, 2003 at 12:55:28PM -0400, Joey Hess wrote: I'd like to see us move all of our setgid games (except, perhaps, nethack) away from using global score files by default. I think that should be a good option, but I can see several games that might suffer by it. Right, such as nethack. Not many though. I'm loath to ask the user if it should be setgid in the installer because that's just needless distraction, but perhaps some global 'setgidnes' setting could be stored in /etc/games? I just threw something in README.Debian and NEWS.Debian about it for xbl. I also think it would be a good idea for policy to require all setuid/gid bit grants to go through this or another list for peer review, much as pre-depends are supposed to. I was thinking of approaching that problem a different way. In the same way that apt-listchanges shows a packages changelog at install time, I could see a script 'apt-listsetuid' which would warn the admin at install time if any new setuid/setgid applications were being installed. (Optionally with the option to remove such bits on a global or per package basis). I've thought this several times, but never quite gotten around to writing the code - if there was any interest I would. That might have more or less the same effect, if developers are the ones who run the script. I don't feel this would be very useful for users though. -- see shy jo pgpaTykjua3P9.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Mon, Nov 25, 2002 at 11:39:04PM +, Steve Kemp wrote: I was wondering if there was a definitive list of all the setuid/setgid binaries which may be installed from the Debian archives. (Such a list would be very useful in prioritizing any examination of source code). I've partially worked my way through the list of packages which are mentioned via the lintian warnings for 'setuid-binary' and 'setgid-binary' which I found at: http://lintian.debian.org/reports/Tsetuid-binary.html and http://lintian.debian.org/reports/Tsetgid-binary.html After that is there any location I could look at Simply use the raw output of lintian, which includes the overridden tags. http://lintian.debian.org/lintian.log Then egrep 'set(g|u)id' lintian.log it, and you'll see the offset from the web pages in O: lines. -- 2. That which causes joy or happiness.
setuid/setgid binaries contained in the Debian repository.
Hi, I was wondering if there was a definitive list of all the setuid/setgid binaries which may be installed from the Debian archives. (Such a list would be very useful in prioritizing any examination of source code). I've partially worked my way through the list of packages which are mentioned via the lintian warnings for 'setuid-binary' and 'setgid-binary' which I found at: http://lintian.debian.org/reports/Tsetuid-binary.html and http://lintian.debian.org/reports/Tsetgid-binary.html After that is there any location I could look at, or if not would there be any interest in such a thing? Steve -- www.steve.org.uk
Re: setuid/setgid binaries contained in the Debian repository.
On Mon, Nov 25, 2002 at 11:39:04PM +, Steve Kemp wrote: I was wondering if there was a definitive list of all the setuid/setgid binaries which may be installed from the Debian archives. (Such a list would be very useful in prioritizing any examination of source code). I've partially worked my way through the list of packages which are mentioned via the lintian warnings for 'setuid-binary' and 'setgid-binary' which I found at: http://lintian.debian.org/reports/Tsetuid-binary.html and http://lintian.debian.org/reports/Tsetgid-binary.html After that is there any location I could look at, or if not would there be any interest in such a thing? There is no such list to my knowledge, but one could be generated with relative ease given a Debian archive (including a CD-ROM set). -- - mdz
