Bad press again...

classic Classic list List threaded Threaded
97 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Sam Hartman-5
On Fri, Aug 26, 2005 at 04:39:04PM +0000, W. Borgert wrote:
> On Fri, Aug 26, 2005 at 05:36:26PM +0200, martin f krafft wrote:
> > Heck, we *should* have a responsive and communicative security team.
>
> Do we have a security team for stable?  I know, that we have a
> security team for testing consisting of nine DDs and ten
> non-DDs, but it seems to me, that stable is handled by Joey
> alone.  Has this changed since the havoc a few months ago?

As far as I know, the stable/oldstable security team was never (recently)
down to Joey S. alone.  Mike Stone and Steve Kemp have been active members
for some time (Steve was, as I understand it, promoted from secretary to
full member within the past couple of months).

It's further my understanding that the other members of the Security Team
listed at <URL: http://www.debian.org/intro/organization > are inactive,
and that some of them have been thus for a very long time.

--
G. Branden Robinson
Debian Project Leader
[hidden email]
http://people.debian.org/~branden/

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Sam Hartman-5
In reply to this post by martin f krafft
On Sat, Aug 27, 2005 at 10:40:36PM +0200, martin f krafft wrote:
> Following the debate around LinuxTag, Branden put a trusted and very
> active and skilled developer on the task to research the security
> problems. Unfortunately, he has not been able to get far with this
> job yet, probably due to numerous reasons. If Branden reads this
> (and he should as it's CC'd), I hope he does something about the
> situation, not by putting pressure on the researcher, but by
> actually causing some change.

The only other point of change I can see is the security team itself.
A couple of possibilities come to mind:

1) the developers propose a GR chartering a new security team (as DPL, I
   can propose a GR without getting seconds first[1]);
2) I bring the Debian Security Team under delegation[2].

Neither of these guarantee that the people appointed to the security will
fulfill the tasks demanded of them -- there is Constitution §2.1.1 to
consider.

> > The email part is very unfortunate indeed, but it probably doesn't
> > warrant drastic measures.
>
> Not if we want Debian to become known as an amateur club and lose
> value among professionals. And yeah, client switching to Solaris may
> tell something about their understanding of security... but then
> isn't it all the more important for Debian to get it right and help
> protect those that don't know better?

[1] Constitution §4.2.1, §5.1.5
[2] Constitution §5.1.1, §8

--
G. Branden Robinson
Debian Project Leader
[hidden email]
http://people.debian.org/~branden/

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Steve Kemp
In reply to this post by Sam Hartman-5
On Mon, Aug 29, 2005 at 11:46:24AM -0500, Branden Robinson / Debian Project Leader wrote:

> As far as I know, the stable/oldstable security team was never (recently)
> down to Joey S. alone.  Mike Stone and Steve Kemp have been active members
> for some time (Steve was, as I understand it, promoted from secretary to
> full member within the past couple of months).

  Steve (me) still remains a secretary, rather than a full member.

Steve
--


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

martin f krafft
In reply to this post by Sam Hartman-5
also sprach Branden Robinson / Debian Project Leader <[hidden email]> [2005.08.29.1846 +0200]:
> As far as I know, the stable/oldstable security team was never (recently)
> down to Joey S. alone.  Mike Stone and Steve Kemp have been active members
> for some time (Steve was, as I understand it, promoted from secretary to
> full member within the past couple of months).

Can you officially confirm this, or can somebody? [0] still lists
him as a secretary, and that's what he said to me when we last
talked since debconf.

0. http://www.debian.org/intro/organization

--
Please do not send copies of list mail to me; I read the list!
 
 .''`.     martin f. krafft <[hidden email]>
: :'  :    proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
micro$oft windows psychic edition:
we will tell you where you are going tomorrow.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Florian Weimer
In reply to this post by Sam Hartman-5
* Branden Robinson:

> 2) I bring the Debian Security Team under delegation[2].

Martin Michlmayr has made the security team a delegate by this
message:

<http://lists.debian.org/debian-devel-announce/2003/05/msg00005.html>

Have you withdrawn this delegation in the meantime?  AIUI, DPL
elections don't rollback the whole organizational framework.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Frans Pop
On Monday 29 August 2005 20:13, Florian Weimer wrote:
> Martin Michlmayr has made the security team a delegate by this
> message:
> <http://lists.debian.org/debian-devel-announce/2003/05/msg00005.html>

Huh? I read no formal delegation in that message.
It just states that he talked to some people and announces that the team
has been extended with one person.
I see no "(as DPL) I appoint" or "I delegate" in that mail.

A, title of the mail is "Delegations". But that may have been be a mistake
on the part of tbm based on the assumption that the security team was
delegated already.

IMO the status of the security team is not changed by that mail: if it was
delegated before that time, it still is, and similar if it was not.

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

martin f krafft
In reply to this post by Florian Weimer
also sprach Florian Weimer <[hidden email]> [2005.08.29.2013 +0200]:
> > 2) I bring the Debian Security Team under delegation[2].
>
> Martin Michlmayr has made the security team a delegate by this
> message:
>
> <http://lists.debian.org/debian-devel-announce/2003/05/msg00005.html>
>
> Have you withdrawn this delegation in the meantime?  AIUI, DPL
> elections don't rollback the whole organizational framework.

Uh, where does it say that the security team is now delegated? It
says mdz was promoted, nothing more or less. Sure, the subject says
"delegations", but that doesn't mean that anything therein is
a delegation. Looks more like tbm actually wanted to write
a different message and forgot to change the subject afterwards. :)

--
Please do not send copies of list mail to me; I read the list!
 
 .''`.     martin f. krafft <[hidden email]>
: :'  :    proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
micro$oft windows psychic edition:
we will tell you where you are going tomorrow.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Florian Weimer
In reply to this post by Frans Pop
* Frans Pop:

> On Monday 29 August 2005 20:13, Florian Weimer wrote:
>> Martin Michlmayr has made the security team a delegate by this
>> message:
>> <http://lists.debian.org/debian-devel-announce/2003/05/msg00005.html>
>
> Huh? I read no formal delegation in that message.

There are no formal requirements for delegations.  As far as the
Constitution is concerned, this message appears to be sufficient to
delegate all the roles which were listed on the web page at that time.

> I see no "(as DPL) I appoint" or "I delegate" in that mail.

This is not necessary.  Delegations need not be made public or even
disclosed to the delegate to be effective.  IMHO, this is a bug in the
Constitution which should be fixed in a GR.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Frans Pop
On Monday 29 August 2005 21:40, Florian Weimer wrote:
> > I see no "(as DPL) I appoint" or "I delegate" in that mail.
>
> This is not necessary.

I'm sorry, but I still think you're doing creative reading. There is only
an announcement of the addition of a new member to an existing team.

There is absolutely no indication that a change of the status of that team
is intended. IMO intention to do so on the part of the DPL is the minimum
requirement for delegation...

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Florian Weimer
* Frans Pop:

> On Monday 29 August 2005 21:40, Florian Weimer wrote:
>> > I see no "(as DPL) I appoint" or "I delegate" in that mail.
>>
>> This is not necessary.
>
> I'm sorry, but I still think you're doing creative reading. There is only
> an announcement of the addition of a new member to an existing team.

I've obtained permission from tbm to quote the message reproduced
below in public.  This should make it clear that the intent was to
delegate: "Nach [URL] hat debian-admin klar die Authorität" --
"according to [URL], debian-admin clearly has authority", and
debian-admin was only listed in the referenced web page.  If the DPL
felt that even that was enough to express delegation, mentioning the
security team in the list message itself should make things even more
clear.

From: Martin Michlmayr <[hidden email]>
Subject: Re: Debian-Aufraeumarbeiten
To: Florian Weimer <[hidden email]>
Date: Sat, 29 Nov 2003 12:26:53 +1100
Message-ID: <[hidden email]>

Hi Florian,

* Florian Weimer <[hidden email]> [2003-11-29 00:22]:
> könntest Du bitte eine kurze Erklärung veröffentlichen, die im
> Nachhinein die Aktionen des Ausfräum-Teams verfassungsgemäß machen?

Die ganze Arbeit wurde von debian-admin erledigt und die haben
klarerweise die Authorität dazu (siehe auch
http://www.debian.org/intro/organization); ich war auch ständig an der
Kommunikation beteiligt.

Nach
http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200305/msg00005.html
hat debian-admin klar die Authorität, also finde ich nicht dass eine
erneute Erklärung notwendig ist.  Aber wenn Du glaubst dass es was
bringt kann ich ruhig was posten (bzw will ich eh etwas schreiben, in
dem ich debian-admin danke - das wäre ja eine implizite Gutheisung).

--
Martin Michlmayr
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Paul Gear
In reply to this post by Florian Weimer
Florian Weimer wrote:
> * Paul Gear:
>
>
>>I don't know upon what you're basing your characterization, but i'm
>>party to at least 3 emails to Joey describing the nature of the bug
>>in sufficient detail to understand it as a security flaw.
>
>
> Was this pre- or post-disclosure?

There was no pre-disclosure.  A bug was reported - the reporter didn't
even realise it was a security flaw, but Tom Eastep, the author, did.
He released a patch and an announcement within a few hours, then we got
to packaging new versions.

> In the latter case, such discussion
> should be Cc:ed to the bug report, IMHO.

Is that a policy issue, common convention, or just a suggestion?

--
Paul
<http://paulgear.webhop.net>
--
Did you know?  Using Microsoft Internet Explorer can make your computer
less secure.  Find out more at <http://browsehappy.com>.

signature.asc (264 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Michael Stone-2
In reply to this post by Florian Weimer
Could we move this thread to -project or -curiosa?

Mike Stone


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Florian Weimer
In reply to this post by Paul Gear
* Paul Gear:

>> In the latter case, such discussion should be Cc:ed to the bug
>> report, IMHO.
>
> Is that a policy issue, common convention, or just a suggestion?

It's a suggestion ("IMHO").  I would like to see it as a common
convention.

I think there are many little things which should be documented
(severity recommendations come to my mind).  However, I'm still
waiting for official feedback on my PHP bug policy document. 8-(


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Paul Gear
In reply to this post by Michael Stone-2
Michael Stone wrote:
> ...
> I also disagree with the characterization that much effort
> has been put into describing the bug.

If we're going to have another crack at it, then, what track should we
take?  Reopen the bug as Florian suggested, email the security team,
just keep pestering Joey?

I didn't mean to stir up so much crap about this problem.  I just want
to see both Debian and Shorewall succeed, and it seems to me that there
are some organisational problems with Debian when it comes to security.
 I want to make sure that we (the upstream team and the maintainer) are
not the cause of them.

It might not seem like it based on my emails, but i'm not really
interested in blame-casting - i just want to see the 222 people who
actually use Shorewall on Debian [1] informed about the possibility that
something could be bypassing their carefully-crafted firewall rules!

[1] http://popcon.debian.org/main/by_inst.gz

--
Paul
<http://paulgear.webhop.net>
--
Please don't CC: me on mailing list messages - i use gmane.org!

signature.asc (264 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Florian Weimer
* Paul Gear:

> If we're going to have another crack at it, then, what track should we
> take?  Reopen the bug as Florian suggested,

According to a recent discussion on -devel, this bug is still open.
The BTS web is a bit confusing.

> email the security team, just keep pestering Joey?

IMHO, the first step would be to convince the shorewall maintainer
that a security update for stable needed. [*] Then someone needs to
prepare an update (preferably the maintainer or someone else who is
familiar with the software).  This is slightly complicated by the
unfortunate fact that the patch in the errate of 2.2.5 does not apply
cleanly to the 2.2.3 version.

> I didn't mean to stir up so much crap about this problem.  I just want
> to see both Debian and Shorewall succeed, and it seems to me that there
> are some organisational problems with Debian when it comes to security.
>  I want to make sure that we (the upstream team and the maintainer) are
> not the cause of them.

Yes, and this is a relatively simple issue and is a good testing
ground.


[*] In the meantime, I've seen upstream's reaction to this bug, and it
makes clear that this is not a mere documentation issue.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Frans Pop
In reply to this post by Florian Weimer
On Monday 29 August 2005 22:23, Florian Weimer wrote:
> I've obtained permission from tbm to quote the message reproduced
> below in public.  This should make it clear that the intent was to
> delegate: "Nach [URL] hat debian-admin klar die Authorität" --
> "according to [URL], debian-admin clearly has authority", and
> debian-admin was only listed in the referenced web page.  If the DPL
> felt that even that was enough to express delegation, mentioning the
> security team in the list message itself should make things even more
> clear.

Does that mean everybody listed in the w.d.o/intro/organization pages is
automatically a delegate in the formal sense? Surely not...
However, this will be my last post on this subject. I remain unconvinced.
Clarification of the status of the current team would be nice.

(BTW. I would have no problem with the security team being delegates. I
just feel that your "evidence" is unconvincing.)

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Michael Stone-2
In reply to this post by Paul Gear
On Tue, Aug 30, 2005 at 06:48:07AM +1000, Paul Gear wrote:
>If we're going to have another crack at it, then, what track should we
>take?  Reopen the bug as Florian suggested, email the security team,
>just keep pestering Joey?

Contact the security team. Describe the bug in such a way that the
security team understands its severity and impact. It is not sufficient
to say "just trust me and issue an advisory". From what I've seen so far
this is not the obvious buffer overflow sort of bug, it's a configured
behavior which deviates from some documented expectation. The question,
then, is how that deviation occurs, what the documented expectation is,
and (most importantly for stable) is there any chance that someone might
be relying on the implemented behavior rather than the documented
behavior.

>interested in blame-casting - i just want to see the 222 people who
>actually use Shorewall on Debian [1] informed about the possibility that
>something could be bypassing their carefully-crafted firewall rules!

ISTM that this is something that they'd notice pretty quick after
testing their rules (or so I guess, since I'm still not entirely clear
about the nature of the bug). And that's the troublesome thing--if it's
an option that nobody uses it's not a big deal, right? But if it is
something someone uses, which they've presumably tested, then there's a
good chance it's working they way they want it to, even if that's not
how it was intended. Without more of an explanation of what's going on,
I'm just guessing.

If the security team does issue an advisory, this is the sort of
examination that needs to happen before writing the text of the
advisory, including possible impacts or changes in behavior. That is why
it is *not* sufficient to simply issue advisories without understanding
what is being issued. To answer your implied question earlier in the
thread, yes, someone from the security team has to "*try* to understand
every security bug". It's not a mechanical process, and our users
presumably expect that we know what we're sending when we issue an
advisory. I'd love if the whole process could be implemented in a simple
script, it would really cut down on the amount of time this security
stuff takes up.

Mike Stone


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Florian Weimer
* Michael Stone:

> Contact the security team. Describe the bug in such a way that the
> security team understands its severity and impact. It is not sufficient
> to say "just trust me and issue an advisory". From what I've seen so far
> this is not the obvious buffer overflow sort of bug, it's a configured
> behavior which deviates from some documented expectation. The question,
> then, is how that deviation occurs, what the documented expectation is,
> and (most importantly for stable) is there any chance that someone might
> be relying on the implemented behavior rather than the documented
> behavior.

It seems that shorewall generates an ACL that ACCEPTs all traffic once
a MAC rule matches.  Further rules are not considered.  The
explanations in version 2.2.3 seem to indicate that this was the
intended behavior, but its implications surprised upstream, and a
corrected version was released.

IMHO, Debian should publish at least a DSA that explains this
discrepancy, especially if the package maintainer also thinks that
it's necessary.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Steve Wray
Florian Weimer wrote:

> * Michael Stone:
>
>
>>Contact the security team. Describe the bug in such a way that the
>>security team understands its severity and impact. It is not sufficient
>>to say "just trust me and issue an advisory". From what I've seen so far
>>this is not the obvious buffer overflow sort of bug, it's a configured
>>behavior which deviates from some documented expectation. The question,
>>then, is how that deviation occurs, what the documented expectation is,
>>and (most importantly for stable) is there any chance that someone might
>>be relying on the implemented behavior rather than the documented
>>behavior.
>
>
> It seems that shorewall generates an ACL that ACCEPTs all traffic once
> a MAC rule matches.  Further rules are not considered.  The
> explanations in version 2.2.3 seem to indicate that this was the
> intended behavior, but its implications surprised upstream, and a
> corrected version was released.
>
> IMHO, Debian should publish at least a DSA that explains this
> discrepancy, especially if the package maintainer also thinks that
> it's necessary.

It seems to be fairly tricky to determine how much of a security risk a
bug has to be before a fix will find its way into stable.

Another example is fwbuilder which *silently* fails to overwrite its
generated script at compile time if the user doesn't have write
permissions on the existing script.

I view this as a security problem because what if you *think* you've
made changes to your firewall and are now protected only... you arn't
and the firewall hasn't been updated?

Is that enough of a security problem for the fix to get into stable?

Who decides?


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bad press again...

Michael Stone-2
In reply to this post by Florian Weimer
On Mon, Aug 29, 2005 at 11:44:59PM +0200, Florian Weimer wrote:
>IMHO, Debian should publish at least a DSA that explains this
>discrepancy, especially if the package maintainer also thinks that
>it's necessary.

Thank you for your input. Would anyone else like to register their
opinion? BTW, did you miss the part where I insinuated that the security
team is looking for some clarification? There's not much point in
issuing an advisory before that, is there?

Mike Stone


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

12345