LWN: Comments on "LCA: The security panel"

Systems disabling themselves when out of date

gdt — Mon, 02 Feb 2009 05:55:04 +0000

This was my suggestion. It is difficult in a Q&A to give a complete system specification, but the notion is that the machine's access to the Internet be curtailed when a distribution is used past its end of support date. I've floated this idea before, see the Fedora Devel "autodie" discussion.

It has been well known for decades that software is not a static construction. Even the old "waterfall model" textbooks warn that most of the cost of software is in its ongoing maintenance. The necessary corollary is that using unmaintained software has an increasing risk of incorrect operation.

For Internet-connected software that risk rises considerably after the end of manufacturer support. Internet-connected systems see continuous testing of their security and eventually a known, unpatched flaw will be exploited. In my role in a large ISP I see a lot more "1000-day exploits" of Linux systems than I see "0-day exploits". Which is not to say that I'm not massively appreciative of SELinux's role in subduing 0-day exploits in Fedora (hint, hint Ubuntu).

I don't understand why people mutter about DRM when I put this forward. Implementing the feature in the operating system leaves the user in control. They can disable the feature or upgrade their software, both with no fear of legislative penalty. That is not the case with DRM.

The risks of enforcing distribution expiry lie more with the fact that computers do things, and those things may be important, and interrupting those important things may have a higher risk than preventing misuse of old software. Good user interface design of the "autodie" feature is an important way to minimise that risk.

LCA: The security panel

nlucas — Fri, 23 Jan 2009 19:17:59 +0000

This reminds me of what I call "scamware".

Some dubious software vendors that sell software with monthly/yearly support contracts that suddenly stop working (with some cryptic error message) when the client decides to stop paying for the support.

This was the case of an accounting software (made by a regional ISV) that stopped working with a "too many files" error 2 months after the last payment, but that would work if the system date was set back.

Now they have an excuse for this: security reasons.

more information

brian — Fri, 23 Jan 2009 00:48:51 +0000

Forcing more information on users will be counter productive. Consider instead putting concise information near where it is relevant.

Systems disabling themselves when out of date

giraffedata — Fri, 23 Jan 2009 00:22:08 +0000

I hope no one seriously proposed that distributors should distribute software that disables the system, as a means of improving security in spite of the owner of that system.

A more legitimate take on this self-destructing system idea is that it's a service to owners who don't want to inadvertently run a vulnerable system. It might even make sense as a default configuration, but as long as a user who has considered what it means to run out-of-service software can easily turn off the feature, I don't see it as a heinous thing.

If I could buy a carton of milk that won't open after its expiration date, I wouldn't mind that one bit. It would save me some ruined cereal.

LCA: The security panel

dlang — Thu, 22 Jan 2009 07:23:04 +0000

the idea of advocating the systems should disable themselves if they decide that they are 'out of date' (whatever that actually means) is very scary

normally it's only the DRM folks who publicly advocate disabling other people's systems, for free software folks to start saying this is very troubling.

In addition, just because a system is 'out of date' or 'officially unsupported' does not mean that it is vunerable to anything. If the system is tightly locked down, on a tightly protected network, or just not running much (among other possibilities) there may be nothing at all wrong with letting it continue to run the old 'out of date' software.

LCA: The security panel

flewellyn — Thu, 22 Jan 2009 06:22:23 +0000

Cliffe's point of view is that users do not really know when they are being asked to make security decisions, so they don't really know when their actions may be putting their security in peril.

That's a sobering thought, and makes me distinctly uneasy. I wonder if one of them, or some other security experts, might be willing to assemble a set of "rules of thumb" about security, and what constitutes real versus imagined security? I'm well aware that there's no generalized definitive answer to this question, and it will depend on the context; still, what are some useful ways to evaluate said context, to determine what is, and is not, secure?