Re: Checking for services to be restarted on a default Debian installation
Long ago I started one thread about making security updates effective, so... On Mon, Sep 01, 2014 at 08:48:25PM +0200, Thijs Kinkhorst wrote: > My questions to this list: > - Do people agree that this would be something that's good to have in a > default installation? Are there drawbacks? Well, one drawback is having to trust a system running potentially vulnerable software. As Debian user I'd like to get the information on how to make updates effective also from the trusted developers and security update folks. Would be nice for DSA's to say "After updating the packages You need to restart the computer", or an optimization like need to re-login, restart browser etc, and maybe even the possibility to automatically do this, or at least prompt the user. This is what Ubuntu has managed to do, AFAIK. https://www.debian.org/security/2014/dsa-3012 "We recommend that you upgrade your eglibc packages." Updating eglibc packages is hardly enough to fix the problem. As a workaround I, and hopefully most users, know about debian-goodies and checkrestart, and figure out on their own if a reboot is necessary. -Mikko -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140901211144.gl9...@lakka.kapsi.fi
Re: ssh-vulnkey and authorized_keys
On Thu, May 15, 2008 at 09:52:10AM +0200, Vladislav Kurz wrote: > It would be also helpful to print the line as dokuwd.pl does. > Is there any repository with newer versions of ssh-vulnkey or dokuwd.pl ? Try the Ubuntu version which contains a fixed ssh-vulnkey ( http://www.ubuntu.com/usn/usn-612-5 ): "Matt Zimmerman discovered that entries in ~/.ssh/authorized_keys with options (such as "no-port-forwarding" or forced commands) were ignored by the new ssh-vulnkey tool introduced in OpenSSH (see USN-612-2). This could cause some compromised keys not to be listed in ssh-vulnkey's output." I think, and hope, Debian openssh packages will be updated too. -Mikko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Security update changelogs?
Hello, packages.debian.org perhaps is the right place to read package changelogs online, but security update changelogs seem to be missing. Where are they? An example: http://packages.debian.org/stable/net/links2 links to non-existing http://packages.debian.org/changelogs/pool/main/l/links2/links2_2.1pre16-1sarge1/changelog -Mikko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mass update deployment strategy
On Mon, Nov 27, 2006 at 03:52:40PM -0500, Morgan Walker wrote: > There is also a package called cron-apt which will automatically update > your debian machines and send you an email regarding what it updated. And upgraded, if you really trust your package sources: $ cat /etc/cron-apt/action.d/9-dist-upgrade dist-upgrade -y -V -u -o Dpkg::Options::=--force-confold -Mikko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1167-1] New apache packages fix several vulnerabilities
On Mon, Sep 04, 2006 at 07:39:16PM +0200, Thorsten Schifferdecker wrote: > you wrote there's a sec-update of apache, but on security.debian.org > no update apache debs where found. Try again a few times. It's on some of the security.debian.org hosts, and propably replicating to all of them. -Mikko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When are security updates effective?
On Sat, Sep 02, 2006 at 10:37:04AM +0200, Rolf Kutz wrote: > * Quoting Mikko Rapeli ([EMAIL PROTECTED]): > > I think it is relevant: should the effectiveness actions in general > > be based on the host where the update was applied through lsof, package > > dependencies provided and digitally signed by Debian, some other information > > provided and digitally signed by the Debian security team in an > > advisory or something else? Or package installation scripts provided by the package maintainer. > The problem here is that when the software has > been exploited already, installing the security > update doesn't fix the problem anymore. Exploited to what extend? Without stack protection, address space randomization, selinux etc, it's very difficult to know wether a processes address space has been violated. And non-privileged processes don't have write access to binary files on the system without additional local root holes. My point is: lsof may not be trustworthy on per host basis when making security updates effective. The time between security bug publication and applying the updates varies too much. If a Linux distro can do better than Windows and not require full reboot after every update, I'd like to see a confirmation of the steps required to make the update effective from a source I trust anyway. -Mikko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When are security updates effective?
On Fri, Sep 01, 2006 at 06:56:17PM -0400, Michael Stone wrote: > On Sat, Sep 02, 2006 at 12:28:17AM +0300, Mikko Rapeli wrote: > >- can a process running vulnerable code be exploited to not show the > > shared libraries and other non-shared libraries and files it had opened > > for reading at some point? > > Of course it can. And that's irrelevant to the question at > hand--installing a security update at that point isn't going to help. I think it is relevant: should the effectiveness actions in general be based on the host where the update was applied through lsof, package dependencies provided and digitally signed by Debian, some other information provided and digitally signed by the Debian security team in an advisory or something else? When an admin takes the chance and trusts lsof, that's fine. If low privilege process starts spamming the world he'll propably notice. But if making these upgrades effective is ever automated, I wouldn't like to take that chance. -Mikko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When are security updates effective?
On Thu, Aug 31, 2006 at 07:23:27PM -0300, Henrique de Moraes Holschuh wrote: > Indeed. lsof +L1 is currently useless for detecting unlinked libraries. > > I've been using lsof | grep "path inode" to detect them for a while now. > Still, I hope the older, saner lsof +L1 behaviour can be restored soon... This got me thinking: - can the output of lsof be trusted when making security updates effective? - can a process running vulnerable code be exploited to not show the shared libraries and other non-shared libraries and files it had opened for reading at some point? - do I assume, fingers crossed, that non of my processes have been tampered with if I trust lsof and don't do a full reboot? AFAIK, shared libraries are just memory mapped files which can be copied and munmap'ed, and an attacker can keep on running his 0wned process on my host and escape my update attempts. I think this applies to all other open files like static and scripting language libraries, data and configuration files too, and even in trusted environments processes don't show all of these loaded 'libraries' via open files. Perhaps package based reverse dependencies give a better idea on what to do after upgrades, but the dep's should be tracked all the way to the executables which started the currently running processes, I think. Strange, but suddenly XP's forced reboot on IE and Acroreader updates starts to make sense... -Mikko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When are security updates effective?
On Tue, Aug 29, 2006 at 10:54:45PM +0200, Moritz Muehlenhoff wrote: > Mikko Rapeli wrote: > > Could Debian security advisories help a bit, since the people making the > > packaging changes propably know how to make the changes effective on a > > running installation too? > > If there's anything special to do (e.g. kernel or glibc) we alredy add this > to the DSA text. Yes, that's great, but some of the non-special cases are not that obvious. Should I reboot or at least restart kdm after libtiff4 update? On one host I get the feeling I don't since 'lsof 2>/dev/null | grep libtiff' returns nothing. Then again this would suggest, that at least kde/kdm needs to be restarted: # apt-cache rdepends libtiff4|grep kde kdelibs4 kdegraphics-kfile-plugins So which one is it? update-notifier seems nice, but how does it know what to do? I looked at the code but couldn't see how it knows when to reboot and when package upgrade is enough. -Mikko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
When are security updates effective?
Files on the file system are updated by the apt[itude] and dpkg. But then what? Most server packages restart the services after upgrades. Most library and desktop application packages don't. Should the local adm take a look at each upgrade and manually check which files changed on the Debian installation, and based on that restart services, programs, kick users out, jump to run level 1 and back, reboot the system etc as suggested by Securing Debian Manual [1]? Could Debian security advisories help a bit, since the people making the packaging changes propably know how to make the changes effective on a running installation too? It seems that Ubuntu advisories already contain a nice notice which defaults to 'you need to reboot your computer to effect the necessary changes' [2] unless the package in question can handle upgrades and 'a standard system upgrade is sufficient to effect the necessary changes' [3] or the package is just an application and 'you need to restart Firefox to effect the necessary changes' [4]. For the record, SUSE advisories also contain this kind of instructions [5] while Fedora [7] and RedHat don't [6]. (The proprietary up2date propably does some magic behind curtains.) If the upgrades have a few standard ways to come effective, then automation for them might be the next step. Has this been discussed somewhere before? -Mikko [1] http://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html#s-security-update [2] https://lists.ubuntu.com/archives/ubuntu-security-announce/2006-August/000378.html [3] https://lists.ubuntu.com/archives/ubuntu-security-announce/2006-July/000375.html [4] https://lists.ubuntu.com/archives/ubuntu-security-announce/2006-August/000377.html [5] http://www.novell.com/linux/security/advisories/2006_48_seamonkey.html [6] https://rhn.redhat.com/errata/RHSA-2006-0582.html [7] https://www.redhat.com/archives/fedora-package-announce/2006-August/msg00099.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1103-1] New Linux kernel 2.6.8 packages fix several vulnerabilities
On Tue, Jun 27, 2006 at 06:16:43PM +0200, Moritz Muehlenhoff wrote: > Mikko Rapeli wrote: > >> http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha > >>/kernel-headers-2.6.8-2_2.6.8-16sarge1_alpha.deb > >^ ^^ > > > > 2.6.8-2 and sarge1? This and older kernel advisories contain URL's and > > md5sums for kernel binary packages which don't fix the mentioned > > vulnerabilities[1]. Is this a bug or am I missing something? > > The Debian security host has been moved to a new machine and as the aftermath > the md5sum template isn't sent out any more. So I had to fiddle this together > manually and accidentally copied over the wrong file. To err is human :) > I'm including the correct ones for reference below, they'll be sent out > officially > signed once the amd64 build is processed. Good. Source and arch indep packages are fine but arch binary lists stil have sarge1 entries dating back to Nov 2005 without fixes from DSA 1103-1. The released fixes seem to add 'sarge[n+1]' version to updated source packages which should propably be in the binary packages version part too. Packages without the new version tag or an old 'sarge[n]' should not be in a kernel DSA, I presume. Or you just copied the wrong list again: > http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/ >kernel-headers-2.6.8-2_2.6.8-16sarge1_alpha.deb ^ ^^ > Size/MD5 checksum: 2757876 e94cdb8d12552d293018c7ca24199f47 > http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/ >kernel-headers-2.6.8-2-generic_2.6.8-16sarge1_alpha.deb ^ ^^ > http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/ >kernel-headers-2.6.8-2_2.6.8-16sarge1_i386.deb ^ ^^ ... -Mikko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1103-1] New Linux kernel 2.6.8 packages fix several vulnerabilities
On Tue, Jun 27, 2006 at 07:00:01AM +0200, Moritz Muehlenhoff wrote: > Upgrade Instructions > - > > wget url > will fetch the file for you > dpkg -i file.deb > will install the referenced file. > > If you are using the apt-get package manager, use the line for > sources.list as given below: > > apt-get update > will update the internal database > apt-get upgrade > will install corrected packages > > You may use an automated update by adding the resources from the > footer to the proper configuration. How about saying also: "Installing, upgrading and dist-upgrading the kernel-image-2.6-[arch] metapackage will keep the installed Debian kernels updated also when kernel package names change due to ABI changes." > http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha >/kernel-headers-2.6.8-2_2.6.8-16sarge1_alpha.deb ^ ^^ 2.6.8-2 and sarge1? This and older kernel advisories contain URL's and md5sums for kernel binary packages which don't fix the mentioned vulnerabilities[1]. Is this a bug or am I missing something? -Mikko [1] $ grep sarge1 dsa-1103-1.txt http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-headers-2.6.8-2_2.6.8-16sarge1_alpha.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-headers-2.6.8-2-generic_2.6.8-16sarge1_alpha.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-headers-2.6.8-2-smp_2.6.8-16sarge1_alpha.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-image-2.6.8-2-generic_2.6.8-16sarge1_alpha.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-image-2.6.8-2-smp_2.6.8-16sarge1_alpha.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-2_2.6.8-6sarge1_hppa.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-2-32_2.6.8-6sarge1_hppa.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-2-32-smp_2.6.8-6sarge1_hppa.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-2-64_2.6.8-6sarge1_hppa.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-2-64-smp_2.6.8-6sarge1_hppa.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-2-32_2.6.8-6sarge1_hppa.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-2-32-smp_2.6.8-6sarge1_hppa.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-2-64_2.6.8-6sarge1_hppa.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-2-64-smp_2.6.8-6sarge1_hppa.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-2_2.6.8-16sarge1_i386.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-2-386_2.6.8-16sarge1_i386.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-2-686_2.6.8-16sarge1_i386.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-2-686-smp_2.6.8-16sarge1_i386.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-2-k7_2.6.8-16sarge1_i386.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-2-k7-smp_2.6.8-16sarge1_i386.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-2-386_2.6.8-16sarge1_i386.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-2-686_2.6.8-16sarge1_i386.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-2-686-smp_2.6.8-16sarge1_i386.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-2-k7_2.6.8-16sarge1_i386.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-2-k7-smp_2.6.8-16sarge1_i386.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2_2.6.8-14sarge1_ia64.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2-itanium_2.6.8-14sarge1_ia64.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2-itanium-smp_2.6.8-14sarge1_ia64.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2-mckinley_2.6.8-14sarge1_ia64.deb http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2-mckinley-smp_2.6.8-14
kernel-image meta packages to sarge installer (was Re: security support for kernel-image-2.4.27-2-XXX discontinued?)
On Thu, Jun 15, 2006 at 02:06:24PM -0400, Joey Hess wrote: > Mikko Rapeli wrote: > > Why isn't kernel-image-2.[4, 6]-[386, 686...] installed by the > > installer, since it is required for kernel security support? > > We didn't think to do that until too late for sarge. Is it too late or too much work to update in a point release too? It seems that d-i's sarge/packages/base-installer/debian/postinst function get_arch_kernel returns a metapackage name for most archs but that information is perhaps lost somewhere in the quite complicated processing of pick_kernel and install_kernel. Even sarge/packages/rootskel/debian/templates-arch fallback for debian-installer/kernel/image[-2.6] selection could perhaps be a metapackage name if - as it seems - it's only fed to apt-get (after checkin that matches an available package name, of course). > > If this is just a sarge thing, could linux-image-2.6-[386...] be > > installed by default in etch? > > It is. Great! -Mikko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: security support for kernel-image-2.4.27-2-XXX discontinued?
On Thu, Jun 15, 2006 at 01:18:12PM +0200, Willi Mann wrote: > The kernel ABI changed, so the change was needed. Install the > kernel-image-2.4-686 (or whatever you need) package. > > http://wiki.debian.org/DebianKernelABIChanges Ok, I'll ask the dumb question which has been on my mind for too long: Why isn't kernel-image-2.[4, 6]-[386, 686...] installed by the installer, since it is required for kernel security support? For the record I've installed the meta package manually since can't remember when but it is not mentioned in Installation Guide, Installer Errata, Debian GNU/Linux 3.1 -- Errata, kernel related advisories... If this is just a sarge thing, could linux-image-2.6-[386...] be installed by default in etch? I tried looking into the sarge and etch installer sources, but couldn't find with mere grepping the list of packages to be installed to the target. -Mikko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
