Re: [SECURITY] [DSA 1565-1] New Linux 2.6.18 packages fix several vulnerabilities

[Mike Gerber]

* Stephen Gran schrieb:
> I also do some rummaging around to figure out what the meta package is
> currently depending on, so that I know what vesion Debian currently
> considers newest, then compare that to /proc/version.  That only works
> for etch and newer kernel images, though, so I think I'll fall back to
> Noah's method for older machines.

I use a small script for Nagios checks that I give the supposed-to-be
booted kernel (e.g. 2.6.18-6-686). I'll change that to have the option 
to check /proc/version instead of uname -r.

I'm more comfortable with changing the Nagios configuration for each
kernel update than by relying on some up-to-date APT cache to determine
the current kernel. But I guess that's a matter of taste.

Cheers,
Mike


signature.asc
Description: Digital signature

Re: [SECURITY] [DSA 1565-1] New Linux 2.6.18 packages fix several vulnerabilities

[Mike Gerber]

Hi,

> Package: linux-2.6
> Vulnerability  : several vulnerabilities
> Problem type   : local
> Debian-specific: no
> CVE Id(s)  : CVE-2007-6694 CVE-2008-0007 CVE-2008-1294 CVE-2008-1375
> [...]
> For the stable distribution (etch), this problem has been fixed in version
> 2.6.18.dfsg.1-18etch3.

Given a system with the package "linux-image-2.6.18-6-686" installed,
version "2.6.18.dfsg.1-18etch3" and:

 # uname -r
 2.6.18-6-686

How do I decide that the fixed kernel is actually booted? Other than by
uptime?

Cheers,
Mike


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

Re: WTF: Debian security, ex. Linux kernel vulnerabilities

[Mike Gerber]

Andreas Barth schrieb/wrote/a écrit/escribió:
> Well, the basic problem with mirrors is:
> * How can we be sure that all mirrors are synced _very_ fast? We will
>   probably get more negative feedback if some mirrors are delayed by
>   more than 10 minutes (and some of our normal mirrors are _way_ worse).

Don't let primary mirrors pull, push the updates to them.


signature.asc
Description: Digital signature

Re: Security risks due to packages that are no longer part of Debian?

[Mike Gerber]

> A tool which lists all packages which are no longer downloadable from
> any APT source would be more helpful, I think.  Does it already exist?

I have a slighty inefficient script for that. I believe there are better 
ways to do what listallpackages does, unknown to the author of the script 
back then ;-) (Reminder to myself: Don't post ugly hacks to mailing
lists.) At least this does its purpose without deselect nor aptitude.

  #!/bin/sh
  helper/listallpackages \
  | while read package version
  do
  
  # Is that version in the apt package lists?
  if ! apt-cache showpkg $package 2>&1 \
  | egrep "(^$version.*/var/lib/apt/lists/)" \
  &>/dev/null
  then
  echo "W: '$package' is not downloadable"
  fi
  done

Where helper/listallpackages is:

  #!/usr/bin/perl 

  $statusfile = '/var/lib/dpkg/status';

  if( -e $statusfile) {
  open(PKG_SOURCE, "< $statusfile") || 
die "Cannot open $statusfile - $!\n";
  $/ = "";  #snarf a paragraph at a time
  while() {
  $clump = $_; 
  if (/Status: install ok installed/) {
  $clump =~ /Package: (.*)/; print "$1 ";
  $clump =~ /Version: (.*)/; 
  $v = $1;
  $v =~ s/\+/\\+/g; print "$v\n";
  }
  }
  close (PKG_SOURCE);
  }


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

Re: murphy in sbl.spamhaus.org

[Mike Gerber]

George Georgalis schrieb/wrote/a écrit/escribió:
> On Fri, Nov 26, 2004 at 10:57:31AM +0100, Florian Weimer wrote:
> >* Christian Storch:
> >> What about greylisting depending on results of e.g. SA?
> >> Only above a limit of scores from SA greylisting would be become active.
> >This is very impolite because it requires that the entire message is
> >transferred at least twice.
> I thought greylisting closes the smtp connection with a temporary
> failure immediately to unfamiliar routers. Then they can transmit the
> message on a second attempt, but since spam relays don't queue, they
> won't try again.

Chrisitan proposed greylisting based on SA scores - that requires the
messages to be transmitted before rejecting them the first time (with
an temporary error), and then to be transmitted again.

It's a matter of time til the spammers begin to implement queues in
their spamware (on some infected Windows zombies). Greylisting is
obsolete then.


pgpPPnWcUtG40.pgp
Description: PGP signature