When discussing systems, or network layouts, or security concerns, we often use the word "trust". Unfortunately, this has led to some confusion, as in this context, we are not using the word "trust" in the conventional sense.
When I say that I trust Dave, it means that not only do I trust him in the conventional sense of trust, but that when the userid daveh signs on to a machine, I have a VERY HIGH expectation that it is in fact Dave at the keyboard. This means that not only that he has not given his password to someone else, but that his office door is locked when he is not there, that no one has ever sniffed his password from the net, that his X sessions have not been tapped via the Xkeys program, his workstation has not been hacked and a trojan horse installed, and a whole range of other exposures that might enable someone else to pretend that they are Dave and use his RCS userid.
Many of these weakness may be outside of Dave's control. There may be hacked machines on his ethernet that have watched him sign on and grabbed his password. He may have been traveling and signed on via some service provider who has been hacked (This is a serious problem). He may have signed on at a public X station and had his keystrokes picked off by the student next to him, or simply had someone shoulder surf his password as he typed it in.
In determining the level of trust, we are not looking at the particular person, but rather we are looking at all the different ways that someone could obtain credentials to impersonate the first person.
While some attacks come via the network, many of the attacks require that the cracker first be signed on the machine as a conventional user. From here, they find holes in the system that let them obtain additional access, and eventually partial control of the machine. From here, they can then use this machine to launch attacks on other machines.
While there are things we can do to close these holes, and we must do what we can, this will be an ongoing task, as every OS upgrade, vendor change, etc, may introduce a new hole. In addition, operational requirements may force us to tolerate holes in vendor software that we do not have the ability to close ourselves. In these cases, we need to isolate these systems behind suitable firewalls to protect the rest of the systems and limit damage.
Given that a cracker only has to be able to break in once, the security of a machine is in part determined by the least trusted user on the machine, and by trust, we are referring to the previous section.
Although many things go into determining the level of trust for a given subnet, we again are faced with the least trusted factor setting the level for the network, and includes all of the machines on that network.
The process isn't easy, but it is important. If you can start with a trusted core, you can then build out from there. We will never be able to trust the entire RPI network, but we can take steps to protect important parts of it (and the associated machines, data and people), and to maintain firebreaks to limit damage, and to establish fire towers in cyberspace to detect and track problems in order to correct them.
The people we are trying to stop are generally not geniuses (they usually have better things to do). Instead, we have vandals in cyberspace who found a set of cracking tools on an anonymous FTP site. They may not understand what they are using, but some of these tools are quite good and finding holes. These people are often very good liars (this is known as social engineering) Ask Gail or Barry or Sharon about some of the second offenders they have dealt with.
These people do often have a lot of time to spend looking for holes. Often there are programs that can help automate or exploit the holes when they find them. If we leave a hole, and someone is willing to invest the time to find it, they will. We must be sure to make that investment too high for anyone who is likely to try, to succeed.