> From: Tim Freeman [mailto:[EMAIL PROTECTED]
...
> 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to