(1) My original thread was, what protection is there in Linux once a piece of executable code is in RAM executing?

(2) The only protection Linux offers is the hardware implementation of 'virtual machine/protected mode' architecture, for which (if it works which I doubt) credit should go to Intel for the design. The fact that Linux makes it work safely on the newest machines (which I doubt) is an afterthought and should have been a no-brainer.

(3) But the flaw in the 'virtual machine/protected mode' architecture (which I believe in) is one of design choice meeting market demands, a flaw created long before any OS should be considered.

(3) You yourself make clear that this is the only 'protection' Linux offers: Intel's architecture, functioning, if not as it should, at least working so it seems. There are no additional software checks and bounds beside Intel's virtual memory paging...

(4) Intel's architecture evolved, both in features, implementation and reliability/safety, leaving behind vulnerabilities in older machines, which have already been exploited by hackers.

(5) On these older machines, and incarnations, isolation of the attached hardware is a myth.

(6) Not cruising on the Web as root is another piece of Linux mythology serving no logical purpose nor protection.

(7) The vulnerabilities and flaws I have been discussing are hardware-based and if Linux provides some protection against them this is marvelous but a Kludge. Good hardware design would be better than a vulnerable software patch.

(8) There are many methods of attacking the integrity of the Linux OS itself, common to any and all software placed in similar circumstances, but I am refusing to discuss those.

(9) I was hoping to hear that Linux had other secondary layers or techniques which would have made me less concerned about security issues, but instead I am now more concerned than when I started this thread.

(10) It is not 'fear mongering' to ask about or discuss plausible attack scenarios. They will of necessity be vague until they are explored and tested thoroughly.

(11) Others here have also voiced concern that certain ideas and theories regarding security and Linux are not based on scientific facts, or logical reasoning principles. I can also be concerned without being accurate on every detail, as long as I am willing to learn. I have already learned a great deal participating in this thread.

I appreciate your concern, reflection, and correction especially as to technical details. Let us continue as friends with the same concerns and interests. Peace.

I have nothing against you but you concerns do not make sense to me. Possibly I do not understand what problems you see.

As to point 6, it shows a complete lack of understanding of the software security model of Linux. The hardware can't be exploited without violating the kernel and the easiest way to violate the kernel is to be a root user (as it permits stuff such as loading kernel modules which are not permitted to non-root users). But, as root, you have all the power in the world to USE the existing system without needing to directly exploit hardware... why bother reading the disk through the bios to write stuff in important areas... when, as a root user, you can just write the files through the OS.

Also, explain to me what "older" system vulnerabilities you are talking about being exploited. I can't explain every single point you security for you if you can't even explain what you are worried about. First, linux does not run on hardware without true memory protection. And it assumes all interrupt controls (which are in a jump table at the bottom of memory... so you can't rewrite it as it is protected by the hardware). User programs can not turn of protected mode (in fact, much of the kernel itself can't even run in unprotected mode... this is why you can get a panic reading memory in the kernel).

The hardware itself it protected as much as possible by the kernel -- although I'll admit there are inherient flaws in the x86 architecture which ANY OS has to deal with. But these flaws are controlled by Linux. Improper instructions which could cause security issues are trapped (for example cli can't be used in a user-program as it could be used to halt the system [cli hlt -- for example]).

Credit should not go to Intel for the design of virtual machines and protected modes. These concepts existed in hardware from many manufacturers. They existed when the 8088 came out but many felt the PC did not require such things as they were meant for single users.

Please, go into more detail about what hardware issues linux does not protect against and you feel are a risk factor.

penguinlnx - you are way off topic. You asked a specific question about the possible effects of IM virus and worm infections on a ? Linux networked system. The answers have been given quite eloquently and clearly in the negative. If you wish to discuss more broad Linux security issues then you should clearly formulate these thoughts on specific areas of vulnerability in the Linux kernel and I am sure some of our gurus will be able to discuss these. With respect, some of your thoughts in this thread are somewhat incoherent.

As an '80s programmer (presumably on microcomputers) you did not have to contend with a hardware memory manager and a preemptive multitasking executive (unless you programmed Amiga, and even then you didn't deal with a hardware memory manager).

What you are worried about is not possible on a modern operating system.

All hardware calls and interrupts are intercepted by the OS. The OS is protected by the hardware memory manager. Hence, a piece of malicious code running in RAM cannot kick the OS out or corrupt the running copy unless it can disable/subvert the memory manager. This can only be done via rootkit, corrupting the OS, and hence invalidating the specific scenario.

(1) To evaluate vulnerability via exploitation thru IM service extensions, it seems reasonable to ask why a cracker would choose them over other methods of intrusion.

(2) No doubt I do have a rather complete misunderstanding of the Linux security model. But hopefully Linux security is not influenced at all by my grasp of it, but rather by properly addressing real or potential vulnerabilities.

(3) When studying exploitation of hardware vulnerabilities under an OS, it seems obvious one should look at how the same hardware has been exploited already under other OS systems for comparison. Rather than moan about discussing Windows security problems, we should be grateful to HAVE a multi-billion dollar experiment running for us at no charge, so Linux can be kept safe and up-to-date.
Are windows users really suckers? Yes: but are they also handy ginea-pigs for Linux users? - YES!

(4) Regarding my 'complete misunderstanding" of my previous point (6), I think it is the other way around. Crackers don't give a damn about whether or not they have ROOT priviledges at the time the system is penetrated. This betrays a naive understanding of penetration methods. A piece of virus-ware doesn't need ROOT now. All it needs to do is remain in stealth mode and periodically check (or not), until ROOT logs on. Root WILL log on eventually. It's a question of patience and long-term strategy, not short-term gratification. A virus may miss hundreds of opportunities to attack, but it only NEEDS one opportunity.

Lets think about HOW a cracker can proceed, according to your own statements:

a) Hardware can't be exploited without violating the Kernel. (great: Crackers like a clear target.)

b) You can violate the kernel is as ROOT. (great: Once inside, poll and wait for an opportunity.)

c) ..by loading Kernel modules etc. (a good start, from which OTHER methods can be activated.)

d) as ROOT you have all the power to expoit the system. (Including turning OFF protected mode!)

e) user programs can't turn off protected mode. (..but they can 'teach' the kernel to do it.)

f) Why work thru BIOS when u control the OS? (...to avoid detection! but more plainly, there are TWO entities fighting over control of the system, but one doesn't know about the other's existance..., and REAL crackers wouldn't count on or bother with the BIOS, except to destroy it.)

g) The flaws in the architecture are controlled by Linux. (That's the question...Is Linux vulnerable?)

h) Explain 'older' system vulnerabilities. (This would be irresponsible. But there are white papers on variations in 'protected mode' designs and implimentation choices.)

i) Credit should not go to INTEL.../ many felt single-user machines didn't need 'protected mode'.
(Well, credit *should* go to INTEL and Windows for leaving the back door open for 20 years! )

j) I base the danger around assumed brilliant programmers. (all innovation in science is tracable to brilliant individuals, not commitees...who else forces change?)

h) arbitrary x86 code can't just ignore the kernel. (I agree. It would immediately modify the kernel, shut off protected mode, take over all the interrupts of the machine, and launch an attack.)

i) the cracker could try escalating priviledges. ( It's easier to just wait for them. ROOT will eventually log on and commit Hari kiri. )

j) a segmentation fault will leave a core dump. ( useless to an attacker? depends on the purpose of the attack. Do you want the system at the local Nuclear plant to stop and do a core-dump? )

k) far-fetched, no grasp of the *nix based system. (It's the nature of the world that all things are fragile, and it is incredibly easy to break things that take incredible intelligence to build. If the goal is to disable or destroy, your technological skill level can be far below the sophistication of the target. But I wouldn't underestimate the capabilities of a determined cracker.)

What I distill out of this long discussion is three main points that haven't been adequately noted:

(1) The OS shouldn't have control of hardware based 'protected mode'. But it does, even in Linux, and this is a vulnerability.

(2) Although various attacks at various stages can be stopped by a combination of methods under Linux, many thousands of Linux machines are vulnerable, because of incomplete security practices. For instance I don't doubt that hundreds of home single-users of Linux don't bother to log out as ROOT, because they feel too safe to bother. And many machine configurations may have hardware vulnerabilities. There are lots of utilities that check file integrity and monitor changes in files, etc, but I will bet that the number of Linux machines having *ALL" such options running all the time is far fewer than imagined. Which is just to say that in practical terms many machines are vulnerable.

(3) It is obvious even to a greenhorn that Microsoft Windows is under extreme attack, something of an all-out guerrilla war. Linux machines are 'never' attacked. Is that because there are more Windows machines than Linux? ha ha ha. Hardly. Who hates Microsoft? Those who are ideologically committed to Linux. Who has the skills to engage in massive internet warfare, and the resources? Large corporations and wealthy individuals who are committed to Linux. How do they launch their attacks? From Linux.

(3b) Does this mean that those committed to Linux are arch--criminals, terrorists, or revolutionaries? No. That's like saying "Christians" are to blame for all the wars, rapes and murders across Europe for the last 1000 years. It completely misses the point: If you were a criminal, you'd need a disguise. You naturally infiltrate, hide, take over and exploit groups that LOOK innocent and benign, because they ARE innocent. Most 'Christians' are just harmless (if sometimes ignorant) followers of Jesus, and most Linux users are not espionage agents or 'terrorist crackers'. But you have to admit its the perfect cover, running with the herd away from ground zero.

Put the crack pipe down ffs.

You clearly stated why an attacker would chose them above other methods. A system may not be running a web-server but if it is running a IM client you have at least one way in. Best of all, it is fairly easy to determine if someone is running an IM client without needing to know their IP address or anything else (as the clients advertise when they are online).

This may seem obvious but it is incorrect. The way hardware is addressed by the OS determines the viability of an attack vector. What works in DOS is not going to have any bearing in Linux. The things we can learn from Windows (like how buffer overflows might be exploited) are shared software issues and do not represent hardware problems.

So what? So root logs in... then what? The code can't just start running as root. Linux doesn't work that way. This is what you don't seem to understand. A process, in memory, is unable to increase its rights. It can only give them up. This is part of the unix fundamental security understanding you lack. If a program starts running as a user, it will continue to run as that user until it dies or the cracker manages to exploit a weakness in the kernel through a local root vulnerability. I've tried to explain this before... see above. The point is that, in every case, the cracker has to work hard for root rights if they can even get code running as a user. By running programs as root you are just handing that to them.

You will never become root just by polling. Nope, your going to have to do something to become root. Further... let's throw a monkey wrench in your whole thing -- security levels. With security levels no one, not even root, can change the kernel. That includes loading modules, changing file-system flags (immutable and such), or running tools which even use the kernel to directly look at disks. While it is true that most people do not turn on their security levels... they do exist and would prevent even root from doing anything.

But, ignoring that... you still don't get root until you DO something. When root logs in it isn't like any running processes become root's. These are multiple user operating systems. Currently my system has processes running as three different users. None of them have the rights of the others. If I had 300 people logged into my machine running stuff... when I logged in as root they wouldn't have any more change of running malicious code than 2 minutes before.

See above. Also... this requires you to be root. A hefty task when exploiting a user's program but a freebie if the program was running as root.

Wrong!!! You couldn't be more wrong if you were Wrongie Wronganstein. No user (not even root) can turn off protected mode. Even a large portion of the kernel (the most privileged "process" on the system) doesn't have the ability to turn off protected mode. Those areas where the kernel needs to work without protection (which are rare) are carefully segregated from everything else, protected, and ensure that the protection is left ON when they leave. It is never possible to run a program or even a couple of commands in a user program without memory protection.

I am so confused about what you are talking about here. Whatever you are smoking... don't Bogart that! Pass it on. There are more interesting things to do besides destroy a BIOS when you have complete control of a system. Go and read up on some rootkits.

Not in any way you seem to think it is.

How would this be irresponsible? You claim to know a lot about them but can't seem to describe anything. Point out these white papers and then please explain how they could be used to exploit a modern OS (even on older hardware). You get no points for refusing to reveal the source of your misunderstanding.

Uhm... okay... two tokes and pass man... don't let it burn away in your fingers.

Please see above. Both of these would never work. It sounds great but it has no basis in reality. Root could log in and out all day and it would never help a user's code (or an attacker's running as a user). And programs can't turn off protected mode... EVER.

Man... if you don't pass that J down... I am going to smack you! Seriously... let's breathe deep (not of that!) and focus. 1) Nuclear power plants are not running IM clients. 2) if a program core-dumps it is the only one to stop running. 3) The control systems in a nuclear power plant are not networked. 4) The control systems have some of the best audited code on the planet (superseded only by NASA and their record of 2 bugs in like a decade). I have a friend who actually works as a nuclear engineer and he would crap his pants from laughing so hard if you proposed that scenario to him. 5) Nuclear control systems are RTOS... which means they aren't Linux and they aren't running on PC hardware.

While there are weaknesses, you seem to have no understanding of what they actually might be. Read... read a lot. Read books on security, read unix design texts, then read the source code itself (to see how it is actually implemented). Or better yet... try and program something to do anything you are talking about... you'll see how futile it is.

3) It is obvious even to a greenhorn that Microsoft Windows is under extreme attack, something of an all-out guerrilla war. Linux machines are 'never' attacked. Is that because there are more Windows machines than Linux? ha ha ha. Hardly. Who hates Microsoft? Those who are ideologically committed to Linux. Who has the skills to engage in massive internet warfare, and the resources? Large corporations and wealthy individuals who are committed to Linux. How do they launch their attacks? From Linux.

Have any facts to back that statement up?

I am smelling something very fishy here! Troll perhaps?????.

If you're going to take on (3) Linux users with vested interest in seeing Microsoft flame out,
Please don't ignore the LARGER paragraph (3b) Criminals disguised as harmless Linux users. Thanks.

RE: 'waiting for ROOT to sign on':

Of course a successful attack probably cannot be 'automatic'. It would be based upon a ROOT user or Administrator copying over files from a safe area to a ROOT area, and/or executing a program because he thought it was safe, or mistook it for something else for instance, because it had misnamed itself. Cheap tricks still work against the unwary. While many a 'virus' may have to wait a long time (perhaps forever) to be activated, this is still a popular method of attack on many systems.

In your larger 'server' systems with various detection and file scanning processes being automated, probably suspicious file activity or illegal operations would mostly be flagged. But that doesn't eliminate user error, even by professional security teams, or protect single inexperienced Linux users.

The most likely and successful attacks are naturally and unknowingly assisted by the victim.

(3b) Does this mean that those committed to Linux are arch--criminals, terrorists, or revolutionaries? No. That's like saying "Christians" are to blame for all the wars, rapes and murders across Europe for the last 1000 years. It completely misses the point: If you were a criminal, you'd need a disguise. You naturally infiltrate, hide, take over and exploit groups that LOOK innocent and benign, because they ARE innocent. Most 'Christians' are just harmless (if sometimes ignorant) followers of Jesus, and most Linux users are not espionage agents or 'terrorist crackers'. But you have to admit its the perfect cover, running with the herd away from ground zero.

If you're going to just spam the thread with selective quotes but not respond with information or logical discussion, let me help you.

Read (3b) again.

To make it clearer:
All gym teachers and boy scout leaders aren't child-molesters (I hope),
but if you were a pervert, it would probably be a great position for you.

Hitler was no Christian, and Crackers are not mere 'Linux enthusiasts'.
But Hitler used the language of 'God' and His purpose for 'the German people', and criminals pick covers and disguises that appear benign.

Ask a Hell's Angel: they're not coke dealers out to pimp your daughter and sell you the video- they're just a bunch of swell guys.

1) By default, root never has ./ as part of their PATH (most systems won't even put that in a user's path). They would have to go out of their way to add it. So, even if they were in a user's home directory with a "virus" disguised as `ls` they would not execute it by mistake.

2) It is not possible for users to write directories in root's PATH. A user can't save a program in /usr/bin for example. So it is not possible to over-write a default utility with a "virus" or place a program some-place where it will be executed by mistake.

3) The ONLY was a program is going to be run by root is if the root user knowingly choses to run it. Which would mean they would have to find it and select the program. This is a completely different thing from what you "intended" to imply -- which was a program automatically running as root when root logged in.

You can talk about social-engineering attacks all day (which is what we have moved into from your "hardware attacks," and your "software attacks." You keep moving the goal-posts trying to find a location of stability for your paranoia. I feel like I am discussing religion with a fundamentalist. The more you point out weaknesses in their worldview the farther they move the point of their conversation.

You started this thread with a very specific topic: IM clients and their vulnerabilities. You have since moved the posts back and forth all over the place in an attempt to justify "something." Not really clear what you are onto.

Your point #3 a AND b... is misguided. As was stated, you are going to need to back up statements like that when you say them. 3b is NOT an escape route for your slander. Please show a case where attackers are mostly Linux users doing it because they hate Windows. You can't point to the second part as an excuse for the first. You said that MOST are okay... fine -- we know that -- but now you need to show that SOME are doing what you said.

Again, I pose the question. Do you have any facts to support those statements from 3 and 3b?

From here, (3) and (3b) taken together support each other, and are self-evident. Not everyone needs to agree. But I pose the counter question: If crackers aren't using Linux servers as well as Windows platforms, what do you think they *are* using?

I did NOT say "The Windows crackers are Linux users." as though that explains the attacks, but rather "Windows crackers use Linux." which is self-evident but does nothing to identify crackers or their motives.

I am happy to explore this issue however, as it is most fascinating. By the way, please don't put all the blame on me for the many directions this thread has gone. I have contributed less than half of the conversation here, And I am not imposing any restrictions whatever upon where others want to lead the conversation. I am not going to tell people what they can or can't talk about. I am interested in participating in a discussion over which I don't WANT control.