Re: Debian security being trashed in Linux Today comments
On Mon, Jan 14, 2002 at 12:17:15PM -0700, John Galt wrote:
>
> Okay, this has gone far enough. The reason that s.d.o only deals with
> stable is that stable is the only part of Debian that by it's nature
> cannot change. For unstable (and now testing) if there's a security bug,
> any DD can put up a NMU if it's severe enough, or the regular maintainer
> can fix it in a [relatively] short amount of time. It's just not feasable
> to expect a change to propagate in stable, because stable doesn't change
> at all, except in very small spurts: there have been 5 revisions to
> potato in the last [going on 2] years. THIS is the reason that there's no
> s.d.o support for testing and unstable. So when woody becomes stable,
> there WILL be s.d.o support for woody, because woody won't change. Unitl
> they become [stagnant,stable], there is just not enough reason to have
> s.d.o support for a distribution.
I think this was well known already, but now that we're sure everyone knows
this, I think Micah's idea is interesting. When things are a long way from
a freeze/release, you're right, John, it's ok to let security be handled in
the current haphazard way it does now. However, how is the testing release
(currently woody) going to get any testing if nobody uses it because it's
security isn't good enough? Some say you should never run unstable or
testing on a machine connected to the internet, but almost all computers are
connected to the Internet, at least as clients. This especially applies to
the home computers of the average hacker, which is the kind of person who
would usefully test and provide feedback on woody. A home system is
somewhere I would use a system that wasn't guaranteed to be secure, and
where I might have to shut down daemons if no security fix was available for
a problem that affected them. (of course I want my machine to be secure, but
I can live without guarantees and check on things myself.) I actually use
woody on my home NAT firewall, which also runs exim and sshd. (These are
the only daemons allowing connections from the outside world on this
machine.)
Hmm, if a security problem which affects unstable and/or testing, but not
stable, is found, what happens? I presume it would get mentioned here, but
is a DSA sent out when it's fixed? Would I have to read Bugtraq or
something to get notification as soon as it's found (so I could shut down an
insecure daemon until the problem was fixed.) I'd rather temporarily give
up the ability to ssh into my home machine and check my email than leave it
open to attack.
> On Mon, 14 Jan 2002, Micah Anderson wrote:
> >As woody draws closer and closer to being stable, and potato draws
> >closer and closer to the legendary dinosaurs which roamed the earth
> >with regards to its outdated software, perhaps this comittment to
> >woody's security could be revisted. I would be surprised if a lot of
> >the criticsm that is coming out on this issue is not related to the
> >fact that a lot of people have moved from potato to woody because they
> >cannot continue to use potato due to the requirements of certain
> >software or underlying libraries, and are thus burned by this security
> >policy.
> >
> > [...]
> >
> >Now that woody draws near to being stable, perhaps the policy can be
> >altered to accomodate for that.
I agree. To get testing better tested (by providing the service more
people need to run it), and to get the security team familiar with the
soon-to-be-stable release, there could be a mechanism for security fixes to
get done on woody, etc. I don't know what kind of security promises would
be appropriate, or what, but I think it would be a good idea to do something
along these lines. Maybe someone should make a list of packages that the
security team would take time to deal with in woody, and add packages to it
over time. Starting with popular packages and/or packages classified as
required/important might make sense.
Here's another idea: Only worry about remote exploits for non-stable dists.
Many of the security advisories apply to local security only, and don't let
a remote attacker get into the machine in the first place. (Many of them
would help an attacker get root after getting a shell running as e.g. nobody
or http). Only worrying about remote exploits in soon-to-be-released dists
would let a lot more people run them "safely", since a lot of home systems
are single user, or at least the other users are trusted/not skilled.
(Think family members and roommates. If they crack your system, you can put
glue on their doorknob or a snowball in their boots :) For important servers
where you really care, like in a business environment, you would certainly
want to stick with stable, so no new holes will be introduced, nothing
breaks, etc. For systems where you are prepared to live with a little
danger, you can run testing and give stuff a workout. When there are known
local exploits that haven't been fixed in the dist you're running, it's like
running your daemons as root. That isn't the case most of the time, only
between when a hole a local priviledge escalation hole is found and when
it's fixed.
The more I think about it, the more I like my idea. :) Even if we don't
worry about testing all the time, it should get some attention as a release
approaches.
Thanks to the security team for all the work you already do. It's much
appreciated. I'm not complaining here, just suggesting ideas.
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@llama.nslug. , ns.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Reply to: