[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [stable] openssl rfc5746 / renegotiation support



On Fri, 19 Nov 2010, Philipp Kern wrote:

> > When we throw out tor 0.2.0.x from lenny, are we replacing it with the
> > version currently in lenny-volatile?
> 
> I'd be ok with that.

Ok, I'll upload it later today.  I'll include the no-coredump patch too,
unless somebody shouts.

Patches attached.
-- 
                           |  .''`.  ** Debian GNU/Linux **
      Peter Palfrader      | : :' :      The  universal
 http://www.palfrader.org/ | `. `'      Operating System
                           |   `-    http://www.debian.org/
From 0856f24277cd984231418420fc7a9dbf7e32bf86 Mon Sep 17 00:00:00 2001
From: Peter Palfrader <peter@palfrader.org>
Date: Sat, 20 Nov 2010 11:30:04 +0100
Subject: [PATCH 1/2] Changelog for upload to lenny as 0.2.1.26-1~lenny+1

---
 debian/changelog |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 62639b7..047276b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,22 @@
+tor (0.2.1.26-1~lenny+1) stable; urgency=low
+
+  * Upload to stable, since a potential future security upload
+    for openssl will break Tor 0.2.0.35, the version currently in
+    stable.
+    .
+    This libssl update will change how openssl does renegotiation,
+    and Tor 0.2.0.x relies on the old behaviour but does not yet
+    know how to tell openssl to stick to it.  The 0.2.1.x tree
+    has special support for newer openssls and sets the proper, new
+    flags so libssl continues to provide the old renegotiation
+    features.
+    .
+    The old-style renegotiation feature is potentially dangerous
+    in some cases, but it is believed that Tor does everything
+    correctly and thus can use it safely.
+
+ -- Peter Palfrader <weasel@debian.org>  Sat, 20 Nov 2010 11:24:32 +0100
+
 tor (0.2.1.26-1~lennyvolatile1) lenny-volatile; urgency=low
 
   * Upload to lenny-volatile.
-- 
1.7.1

From 3b9ecd3001478b15a0c418f4e825d4fea98de426 Mon Sep 17 00:00:00 2001
From: Peter Palfrader <peter@palfrader.org>
Date: Sat, 20 Nov 2010 11:32:36 +0100
Subject: [PATCH 2/2] disable coredumps by default

Up until now the init script (or actually /etc/default/tor) raised
the ulimit for coredumps to unlimited, so that Tor would produce
coredumps on assert errors or segfaults.  Coredumps however can
leak sensitive information, like cryptographic session keys and
clients' data should the core files get into the wrong hands.  As
such it seems prudent to only enable coredumps if the user or
operator explicitly asks for them, and knows what to do with them.

Also include a cron.weekly job that removes old coredumps from /var/lib/tor.
This action can be disabled in etc/default/tor.

Cherry-picked from debian-0.2.1.  Original commit is
270ed52406acd28eea57114acf04ba7d63cedad5.

Conflicts:

	debian/changelog
---
 debian/changelog       |   10 ++++++++++
 debian/rules           |    1 +
 debian/tor.cron.weekly |   14 ++++++++++++++
 debian/tor.default     |   20 ++++++++++++++++++--
 4 files changed, 43 insertions(+), 2 deletions(-)
 create mode 100755 debian/tor.cron.weekly

diff --git a/debian/changelog b/debian/changelog
index 047276b..1ce1cd6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,6 +14,16 @@ tor (0.2.1.26-1~lenny+1) stable; urgency=low
     The old-style renegotiation feature is potentially dangerous
     in some cases, but it is believed that Tor does everything
     correctly and thus can use it safely.
+  * No longer set ulimit -c to unlimited:
+    Up until now the init script (or actually /etc/default/tor) raised
+    the ulimit for coredumps to unlimited, so that Tor would produce
+    coredumps on assert errors or segfaults.  Coredumps however can
+    leak sensitive information, like cryptographic session keys and
+    clients' data should the core files get into the wrong hands.  As
+    such it seems prudent to only enable coredumps if the user or
+    operator explicitly asks for them, and knows what to do with them.
+  * Also include a cron.weekly job that removes old coredumps from
+    /var/lib/tor.  This action can be disabled in /etc/default/tor.
 
  -- Peter Palfrader <weasel@debian.org>  Sat, 20 Nov 2010 11:24:32 +0100
 
diff --git a/debian/rules b/debian/rules
index f5aaa95..5c6a302 100755
--- a/debian/rules
+++ b/debian/rules
@@ -187,6 +187,7 @@ binary-common:
 	dh_installexamples
 	dh_installlogrotate
 	dh_installinit
+	dh_installcron
 	dh_installman
 	dh_link
 	dh_strip --dbg-package=tor-dbg
diff --git a/debian/tor.cron.weekly b/debian/tor.cron.weekly
new file mode 100755
index 0000000..ae4469d
--- /dev/null
+++ b/debian/tor.cron.weekly
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+set -u
+
+DEFAULTSFILE=/etc/default/tor
+
+if [ -f $DEFAULTSFILE ] ; then
+	. $DEFAULTSFILE
+fi
+
+if [ "${CLEANUP_OLD_COREFILES:-}" = "y" ] ; then
+	find /var/lib/tor -mindepth 1 -maxdepth 1 -type f -mtime +21 -user debian-tor -regex '.*/core\(\.[0-9]+\)?' -exec rm '{}' +
+fi
diff --git a/debian/tor.default b/debian/tor.default
index 48127cc..1cc0601 100644
--- a/debian/tor.default
+++ b/debian/tor.default
@@ -34,9 +34,25 @@ RUN_DAEMON="yes"
 # ARGS=""
 
 #
-# Comment this out if you do not want to get coredumps
+# Uncomment the ulimit call below if you want tor to produce coredumps on
+# segfaults and assert errors.
 #
-ulimit -c unlimited
+# Keeping coredumps around is some sort of security issue since they
+# may leak session keys, sensitive client data and more, should such
+# files fall into the wrong hands.  Therefore coredumps are not enabled
+# by default.
+#
+# ulimit -c unlimited
+
+#
+# Config option for the weekly cron file: Whether or not to remove old
+# coredumps in /var/lib/tor.  Coredumps can hold sensitive data, as such
+# they probably should not be kept lying around if nobody will ever look
+# at them.  This option makes /etc/cron.weekly/tor clean out files older
+# then three weeks.
+#
+CLEANUP_OLD_COREFILES=y
+
 
 # Let the vidalia package override some of our settings.
 # People who have vidalia installed might not want to run Tor as a system
-- 
1.7.1


Reply to: