> 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