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

RE: Guarding against evil software installation scripts?



> From: Tim Freeman [mailto:tim@fungible.com]
...
> But whose reputation?

The package maintainer directly, the Debian project indirectly.

I'm not really talking about individuals, I'm talking about generalities.

On a really secure machine, you're not going to be installing games, or utilities willy-nilly anyway. A secure machine will run its own iptables/ipchains filter to prevent unauthorized or unknown packets from entering or leaving the system itself, and sit behind a firewall or filtering router too. At least.

One of the things I liked about Debian from the first time I used it, was the granularity of package install. Telnet, fingerd, ftpd, NFS, rsh, etc., have never been installed. A service that does not exist cannot be exploited.

> If we could make it so that only some packages need to install as
> root, and the rest are prevented from arbitrarily modifying the
> machine, then the intruder has to arrange to be in the root package
> group to do much harm. This could at least require more social
> interaction and more time than creating ordinary user-mode packages.

I agree, this would be a GoodThing(tm, reg us pat off).

The kinds of segmentation and isolation are addressed quite carefully in Security Enhanced Linux (SELinux) that is being developed and released by the American National Security Agency. Their white papers discuss the details, and for a machine you must leave accessible from the outside world, but must also secure to such a degree, it might be worth the trouble.

http://www.nsa.gov/selinux/

As I've said for many years, "Security Is Inconvenient." Your level of security truly depends on how much effort you're willing to expend. Running as root is very convenient indeed.

> I don't know the required size of the developer group before you can
> expect to have a patient evil person in the group.  Apparently we
> aren't there yet, and that's a good thing.

Such evil tends to be self limiting. When(if) discovered, the individuals ability to continue to perpetrate evil is decreased. In a situation like Linux, where no one individual has complete control over anything, or the ability to use force, such evil would be very short lived. People would simply use something else.

In a closed source system, a back-door can be put in easily. If its carefully and deliberately placed, it could well go undiscovered. A login program with a hard-coded username, for instance. Something like that wouldn't withstand any level of examination of the source.

OpenSource lends itself to being secure against the most likely threats: well known exploits by script kiddies. OpenSource systems are updated more rapidly, and with far more granularity than closed systems. The results of Honey pot projects are fascinating reading. Hint: Never leave a system in its "default" configuration.

There is a great deal to be learned on both sides, by comparing physical and data security models. The data model, for instance, has to deal with the fact that an attack is not just "likely", it's inevitable. The likelihood of any particular exploit being attempted depends on how well known it is, and how long it's been around.

It is common practice in physical security to identify what level of attack is expected, and then engineer for it. There is a point for most people at which it is more cost effective to carry insurance against something that is massively destructive, but very unlikely. Like a meteor strike, or airplane crash. 

Argumentum ad absurdum, security at American airbases in the middle east is designed around attack by, "a motivated, well organized, well supplied and capable group."

Physical security is still breached often by "the oldest trick in the book" such as someone carrying a clipboard and wearing a lab coat who "tailgates" into a secure area by looking like everyone else.

And SirCam shows, such socially engineered viruses work on computers too.

Oh heck, I'm rambling. Three times in three days, will the Debian Security list ever forgive me?

Curt-


-- 
To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: