What Mechanisms Keep Network Processes (and Applications) Sandboxed

Question

This question stems from my other question, sorry if it is too similar. Now I would like to know what mechanism is used to sandbox network processes and (if relevant) individual programs, if at all?

Obviously, if the local machine is comporomised and someone has a screensharing program or keylogger installed, all bets are off. I also now that the processor is sandboxed into protection rings, and network information is seperated at some layer of the protocol stack, probably somewhere in the IP/TCP/Session/Application layers along with their unique port numbers used for identification. (Additional clarification on my two previous vague points about rings and layers with relation to my question would be informative).

Scenario: You are doing banking on your web browser with outgoing Port 80 and random uncommon incoming ports. I open a legitimate local Java program which accesses information on the internet on a different port. What kind of crosstalk may be possible? (If language matters, i.e. something other than Java, please explain).

As in my other question, I am not talking about actively malicous software. More like, what is possible for the Java program or Web browser to detect about each other in a normal environment. Obviously, it would be considered malicious for either program to obtain and send information about the network process without the user's permission... but how far out can each process reach?

Analogy For Asking: Original hubs worked by transmitting information on all ports to all clients which posed a significant LAN concern. All a NIC adapter had to do to listen was to not discard frames not destined for itself. However, this was considered to be normal operation. Is there some reason I should not run banking and other external Java programs simultaneously? If the machine is comporomised completely, then obviously this makes no difference. But I am asking... well I hope you know by now.

CLARIFICATION: My question generally deals with programs which are creating sockets and such. Obviously, all of these programs share a common foundation, the CPU and memory, but programs that do not open ports, or are blocked by the software firewall by default, do not concern me as much. Or should they?

Answer 1

What you are talking about deals with a few different layers of the OSI model:

At layer 7 (Application) you have your web-app starting to communicate with the bank's host (as an example). It initiates a request for communications that is handled by Layer 5 (Session) that creates and maintains the communications channel between the applications. The result is called a socket in common terms. All of the transported data is handled by layer 4 (Transport) which in turn is directed by Layer 3 (Network) which guides the ethernet frame/IP Packet to it's destination, all of which flows through layer 2 (DataLink) which is responsible for handling the modification of the frames for transport onto Layer 1 (physical) the wire or wireless communication.

Layer 6 (presentation) converts or modifies the data being sent, so that it can be understood at both ends by the applications using the data.

Each application running, that requires network communications, goes through that sort of process, and information from each socket is given to the application that opened it. As for most non-malicious programs, they (probably) do not obtain or view information sent to you on other sockets. So, to answer your question, generally there is no reason to not run multiple applications simultaneously. Java-based apps still use their own sockets, and the OS handles which information goes where.

However, since ALL of your information goes through a common layer 2 and layer 1 section, (NIC / Wire / Radio), it is possible to craft applications that can capture and record ALL NETWORK TRAFFIC locally on your machine. (In fact many exist, take Wireshark for example) Since that is the case, it is very possible for some applications to view or take actions based on that captured data. There are a few other attacks that can be used to hijack the session(socket), and obtain the information at that level as well.

What can be done to secure it? Encryption of the data at different layers can prevent capture of readable or usable data by programs that might want to "peek" at your information. But that is a much different monster and comes with it's own fun bits.

I'm relatively new to the whole networking thing, but understanding the OSI model and how it conceptualizes networking goes a LONG LONG way towards understanding it.

Answer 2

There are in fact solutions to prevent processes from accessing traffic of other processes, although they have their limits and usually are restricted to a local network. But for at least some security envrionments, that's sufficient.

The keyword here would be "Netlabel". Those are labels appended to IP packets, containing security information about the transferred content.

I'm not up to date on that topic, but it looks like SElinux provides some sort of labeling-functionality. Since I can only post two links with my rep, ask google for "nb networking selinux". The first hit provides some information about that topic regarding SElinux.

Additionally, there are commercial solutions which often use CIPSO for labeling. A rather short summary of CIPSO is available here, and here is the draft. CIPSO is quite old when you're looking at the draft, but it's being used today for exactly that purpose: to secure content flowing through networks, making sure unauthorized subjects won't be able to capture the data.

Answer 3

Single use systems are the only method against cross domain attacks. Paradoxically moore's law has made this impossible.

There are mitigation techniques across each of the OSI layer, but fundamentally only work in a narrow band. Once you factor in the political/structural aspect of things, you'll find the only way to safeguard anything is to produce an extreme structured way of transfer. And to have mitigation processes in place to stop disruptions.