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
Reply to: