Re: The harden-*flaws packages.

[Colin Watson]

On Thu, Aug 29, 2002 at 02:35:13PM +0200, Ola Lundqvist wrote:
> I'm the maintainer of the harden-*flaws packages. The idea is to
> have conflicts with packages that are known to have security holes.
> This is not a big problem for unstable (and mostly for testing)
> but now woody have become stable.
> 
> So I now ask you what you think. Should I upload updated conflicts
> for woody or should I just let it be as is (the packages are
> then quite useless in woody). Or should I upload new ones. With
> which priority and for what distribution name? "woody-proposed-updates",
> "woody", "woody-security-updates" or what?

I'm not honestly sure why it helps. Surely in order to see the new
harden-*flaws packages, people will have to update, and at that point
they will see the new packages anyway? I don't understand why somebody
would upgrade harden-*flaws and not the security updates themselves. As
far as I can tell, harden-*flaws is only useful for security holes for
which no fix is available.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: The harden-*flaws packages.

[Ola Lundqvist]

Hi

On Thu, Aug 29, 2002 at 01:39:35PM +0100, Colin Watson wrote:
> On Thu, Aug 29, 2002 at 02:35:13PM +0200, Ola Lundqvist wrote:
> > I'm the maintainer of the harden-*flaws packages. The idea is to
> > have conflicts with packages that are known to have security holes.
> > This is not a big problem for unstable (and mostly for testing)
> > but now woody have become stable.
> > 
> > So I now ask you what you think. Should I upload updated conflicts
> > for woody or should I just let it be as is (the packages are
> > then quite useless in woody). Or should I upload new ones. With
> > which priority and for what distribution name? "woody-proposed-updates",
> > "woody", "woody-security-updates" or what?
> 
> I'm not honestly sure why it helps. Surely in order to see the new
> harden-*flaws packages, people will have to update, and at that point
> they will see the new packages anyway? I don't understand why somebody
> would upgrade harden-*flaws and not the security updates themselves. As

Well there is one reason why you could like this (and one of the reasons
why I wrote them) and that is if you have a own package repository
or a repository that is not a official site.

You do probably not want to upgrade everything (if you have such a system)
so to check with the *flaws package can be a good thing.

> far as I can tell, harden-*flaws is only useful for security holes for
> which no fix is available.

That is a reason too. I have almost never got any information about any
bug that is not fixed. It happens but is not very common.

But of course stable should remain stable and this kind of uploads
are not very critical (or?).

Regards,

// Ola

> -- 
> Colin Watson  [EMAIL PROTECTED]
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Re: The harden-*flaws packages.

[Martin Schulze]

Please see the thread summarized in 
:

Policy for Woody Point-Releases. [4]Several [5]developers [6]would
[7]like to add new packages and updates to their packages to the
recently released stable distribution of Debian. Adding new packages
and random updates to the stable distribution, however, would nullify
the entire idea of having a stable release, Joey [8]explained. Hence,
the same policy as before will be used for point-releases of woody.

 4. http://lists.debian.org/debian-devel-0207/msg01411.html
 5. http://lists.debian.org/debian-devel-0207/msg01416.html
 6. http://lists.debian.org/debian-devel-0207/msg01614.html
 7. http://lists.debian.org/debian-devel-0207/msg01483.html
 8. http://lists.debian.org/debian-devel-0207/msg01641.html

Regards,

Joey

-- 
Linux - the choice of a GNU generation.

Re: The harden-*flaws packages.

[Daniel Martin]

Martin Schulze <[EMAIL PROTECTED]> writes:

> Please see the thread summarized in 
> :
> 
> Policy for Woody Point-Releases. [4]Several [5]developers [6]would
> [7]like to add new packages and updates to their packages to the
> recently released stable distribution of Debian. Adding new packages
> and random updates to the stable distribution, however, would nullify
> the entire idea of having a stable release, Joey [8]explained. Hence,
> the same policy as before will be used for point-releases of woody.

Yes, but how does this apply to a package that does nothing but
conflict with existing packages?  (As is the case with most of the
harden-* packages)

Agreed, _random_ updates would be a bad thing.  However, what the
maintainer is proposing here is updates that are driven by DSAs.
Although I find it a slight stretch, one could easily argue that the
updates to the harden-*flaws packages are security updates.

These updates share another feature with security updates.  Imagine
the package netostrich, which helps you bury your head in the sand
remotely.  Now, suppose the upstream authors discover a flaw in the
2.0 series of netostrich prior to version 2.33 which allows random
network users to bury other people's heads in the sand.  Sarge soon
contains 2.34 with the security fix, yet woody contains 2.29.1 with a
backported fix.  Then there would similarly need to be two
harden-remoteflaws; one for woody, which conflicts with netostrich
prior to 2.29.1, and one for sarge, which conflicts with netostrich
prior to 2.34.  The harden-*flaws update has to be backported along
with the backported fix to netostrich.

Now, if we want the harden-remoteflaws package to be at all useful, it
needs to be updated along with DSAs...

Hrm.  The more I think about this the more I wonder if maybe the
harden-*flaws packages make much sense in stable at all.  If someone
is apt-get'ing from security.debian.org, they're already replacing
vulnerable versions with fixed ones.  If someone is updating from a
point release CD, the same thing applies.  The only case where I can
see it making sense is with someone following testing with most of
their packages on hold (they really want a stable system, and only
upgrade a package when they need to).  Am I missing a scenario?

Re: The harden-*flaws packages.

[Ola Lundqvist]

Hi

Thanks for the arguing.

On Sun, Sep 01, 2002 at 09:22:56PM -0400, Daniel Martin wrote:
> Martin Schulze <[EMAIL PROTECTED]> writes:
> 
> > Please see the thread summarized in 
> > :
> > 
> > Policy for Woody Point-Releases. [4]Several [5]developers [6]would
> > [7]like to add new packages and updates to their packages to the
> > recently released stable distribution of Debian. Adding new packages
> > and random updates to the stable distribution, however, would nullify
> > the entire idea of having a stable release, Joey [8]explained. Hence,
> > the same policy as before will be used for point-releases of woody.
> 
> Yes, but how does this apply to a package that does nothing but
> conflict with existing packages?  (As is the case with most of the
> harden-* packages)
> 
> Agreed, _random_ updates would be a bad thing.  However, what the
> maintainer is proposing here is updates that are driven by DSAs.
> Although I find it a slight stretch, one could easily argue that the
> updates to the harden-*flaws packages are security updates.
> 
> These updates share another feature with security updates.  Imagine
> the package netostrich, which helps you bury your head in the sand
> remotely.  Now, suppose the upstream authors discover a flaw in the
> 2.0 series of netostrich prior to version 2.33 which allows random
> network users to bury other people's heads in the sand.  Sarge soon
> contains 2.34 with the security fix, yet woody contains 2.29.1 with a
> backported fix.  Then there would similarly need to be two
> harden-remoteflaws; one for woody, which conflicts with netostrich
> prior to 2.29.1, and one for sarge, which conflicts with netostrich
> prior to 2.34.  The harden-*flaws update has to be backported along
> with the backported fix to netostrich.
> 
> Now, if we want the harden-remoteflaws package to be at all useful, it
> needs to be updated along with DSAs...

Yes. Luckily I just saw someone that have written a script that checks
the DSA:s and tell the maintainer that he/she has a vulnerable package.
That is a good solution (best?). The problem is that the DSA is 
not able to distinguish between local/remote/3rdparty flaws but
that is not always interesting.

> Hrm.  The more I think about this the more I wonder if maybe the
> harden-*flaws packages make much sense in stable at all.  If someone
> is apt-get'ing from security.debian.org, they're already replacing
> vulnerable versions with fixed ones.  If someone is updating from a
> point release CD, the same thing applies.  The only case where I can
> see it making sense is with someone following testing with most of
> their packages on hold (they really want a stable system, and only
> upgrade a package when they need to).  Am I missing a scenario?

Yes. When you have a lot of own-compiled debs in an other archive
which can be more or less stable.

So my suggestion (which it probably will be) is that the harden-*flaws
package either contain that (or such a) script or depend on it.

Maybe I will merge the *flaws into a flaws package.

Regards,

// Ola

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

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Re: The harden-*flaws packages.

[Goswin Brederlow]

Daniel Martin <[EMAIL PROTECTED]> writes:

> Martin Schulze <[EMAIL PROTECTED]> writes:
> 
> Hrm.  The more I think about this the more I wonder if maybe the
> harden-*flaws packages make much sense in stable at all.  If someone
> is apt-get'ing from security.debian.org, they're already replacing
> vulnerable versions with fixed ones.  If someone is updating from a
> point release CD, the same thing applies.  The only case where I can
> see it making sense is with someone following testing with most of
> their packages on hold (they really want a stable system, and only
> upgrade a package when they need to).  Am I missing a scenario?

They should have stable as their distribution with highest priority
for apt. That includes security for stable.

On top of that the few packages they want more current can be
installed from woody or sid. No need to keep everything else on hold,
making stable first priority for apt should be enough.

And then they would get security updates.

MfG
Goswin

Re: The harden-*flaws packages.

[Javier Fernández-Sanguino Peña]

On Mon, Sep 02, 2002 at 08:47:53AM +0200, Ola Lundqvist wrote:
> 
> Yes. Luckily I just saw someone that have written a script that checks
> the DSA:s and tell the maintainer that he/she has a vulnerable package.
> That is a good solution (best?). The problem is that the DSA is 
> not able to distinguish between local/remote/3rdparty flaws but
> that is not always interesting.

Why duplicate the work the Tiger package is already doing? I do not see the 
merit
of checking *only* for DSAs published in the RDF file (since that RDF file is
limited to a few DSAs only).

If you want a program to check for security flaws please use one designed for 
that
precisely. Tiger is such a program. Just have the *flaws package recommend: or
depend: on tiger.

Of course, there is room for improvement, the DSAs could be parsed from the WML
source to retrieve both the description *and* wether it's a local or remote 
issue
and populate the report accordingly (it currently just checks against version
packages) *also* we could provide MD5sums of know vulnerable packages (in the
stable distribution and proposed-updates).

Also, this information needs to be splitted off the package so it can work like
antivirus updates. Thus, signature updates could go to proposed-updates without
needing to update the program itself.

Regards

Javi

Re: The harden-*flaws packages.

[Ola Lundqvist]

Hi

On Mon, Sep 02, 2002 at 03:09:28PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Mon, Sep 02, 2002 at 08:47:53AM +0200, Ola Lundqvist wrote:
> > 
> > Yes. Luckily I just saw someone that have written a script that checks
> > the DSA:s and tell the maintainer that he/she has a vulnerable package.
> > That is a good solution (best?). The problem is that the DSA is 
> > not able to distinguish between local/remote/3rdparty flaws but
> > that is not always interesting.
> 
> Why duplicate the work the Tiger package is already doing? I do not see the 
> merit
> of checking *only* for DSAs published in the RDF file (since that RDF file is
> limited to a few DSAs only).

Well my thought was to check for all DSA:s which apparently this script do not.

> If you want a program to check for security flaws please use one designed for 
> that
> precisely. Tiger is such a program. Just have the *flaws package recommend: or
> depend: on tiger.

On the other hand tigher does a lot of other things too. But the link
you gave me was very interesting.

> Of course, there is room for improvement, the DSAs could be parsed from the 
> WML
> source to retrieve both the description *and* wether it's a local or remote 
> issue
> and populate the report accordingly (it currently just checks against version
> packages) *also* we could provide MD5sums of know vulnerable packages (in the
> stable distribution and proposed-updates).
> 
> Also, this information needs to be splitted off the package so it can work 
> like
> antivirus updates. Thus, signature updates could go to proposed-updates 
> without
> needing to update the program itself.

Agreed. Without having too much digging in tiger it might be a good
idea. The contact I have had with tiger is not very pleasant because it
bugged me with a lot of non-issues. That is maybe the reason why I
deinstalled it. :)

Regards,

// Ola

>   Regards
> 
>   Javi
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Re: The harden-*flaws packages.

[Javier Fernández-Sanguino Peña]

On Mon, Sep 02, 2002 at 04:09:21PM +0200, Ola Lundqvist wrote:
> Hi
> 
> > If you want a program to check for security flaws please use one designed 
> > for that
> > precisely. Tiger is such a program. Just have the *flaws package recommend: 
> > or
> > depend: on tiger.
> 
> On the other hand tigher does a lot of other things too. But the link
> you gave me was very interesting.

Tiger can be configured easily to just check *one* thing. Just customize the 
cron
job at will.

(..)
> 
> Agreed. Without having too much digging in tiger it might be a good
> idea. The contact I have had with tiger is not very pleasant because it
> bugged me with a lot of non-issues. That is maybe the reason why I
> deinstalled it. :)

There are still false positives in tiger, the template mechanism, however, takes
care so that an admin just sees a security warning *once* and not in every run 
of
the security test script (It's a simple diff, mind you, but it works)

Regards

Javi

Re: The harden-*flaws packages.

[Ola Lundqvist]

On Mon, Sep 02, 2002 at 05:01:14PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Mon, Sep 02, 2002 at 04:09:21PM +0200, Ola Lundqvist wrote:
> > Hi
> > 
> > > If you want a program to check for security flaws please use one designed 
> > > for that
> > > precisely. Tiger is such a program. Just have the *flaws package 
> > > recommend: or
> > > depend: on tiger.
> > 
> > On the other hand tigher does a lot of other things too. But the link
> > you gave me was very interesting.
> 
> Tiger can be configured easily to just check *one* thing. Just customize the 
> cron
> job at will.

That can be interesting for the harden-*flaws pacakges (or similar).

> (..)
> > 
> > Agreed. Without having too much digging in tiger it might be a good
> > idea. The contact I have had with tiger is not very pleasant because it
> > bugged me with a lot of non-issues. That is maybe the reason why I
> > deinstalled it. :)
> 
> There are still false positives in tiger, the template mechanism, however, 
> takes
> care so that an admin just sees a security warning *once* and not in every 
> run of
> the security test script (It's a simple diff, mind you, but it works)

Ahh that looks great. Last time I checked it did not. Now I might be
able to use it again. :)

Now we just have to solve the upload-to-security problem, or simply
write some other check that scans the security.d.o web pages and
make clever things of it. Maybe using tiger, maybe some other things. But
because tiger can do similar things that might be useful.

Regards,

// Ola

>   Regards
> 
>   Javi
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Re: The harden-*flaws packages.

[Javier Fernández-Sanguino Peña]

On Mon, Sep 02, 2002 at 05:13:51PM +0200, Ola Lundqvist wrote:
> 
> Now we just have to solve the upload-to-security problem, or simply
> write some other check that scans the security.d.o web pages and
> make clever things of it. Maybe using tiger, maybe some other things. But
> because tiger can do similar things that might be useful.
> 
It's in my todo list. Now DSAs are much more easy to parse. Some older DSAs
(pre-1999) might need special parsing however. Also, DSAs could be improved to 
add
an 'affected versions' tag (currently only the package name is provider, you can
infer the affected versions by looking the versions which *fix* the 
vulnerability).

Javi

Re: The harden-*flaws packages.

[Ola Lundqvist]

On Mon, Sep 02, 2002 at 06:28:44PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Mon, Sep 02, 2002 at 05:13:51PM +0200, Ola Lundqvist wrote:
> > 
> > Now we just have to solve the upload-to-security problem, or simply
> > write some other check that scans the security.d.o web pages and
> > make clever things of it. Maybe using tiger, maybe some other things. But
> > because tiger can do similar things that might be useful.
> > 
> It's in my todo list. Now DSAs are much more easy to parse. Some older DSAs
Nice (that it is on your todo list).

> (pre-1999) might need special parsing however. Also, DSAs could be improved 
> to add

The really old ones is probably not valid because this kind of check will
be added to a release where such packages simply can not be hold back.

> an 'affected versions' tag (currently only the package name is provider, you 
> can
> infer the affected versions by looking the versions which *fix* the 
> vulnerability).

Most the time it is not that easy to know each and every version that is
affected so infering is probably the way to go. Do you want help with this
and do you have anything for a starter?

Regards,

// Ola

>   Javi
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---