Android SDK provides LocalSocket objects for IPC over Unix Domain Sockets, but does so using Linux abstract namespaces. As such, any process can bind to the server socket, where standard Unix sockets generally require read/write permission to access the sockets file descriptor. I can see many vulnerabilities that can arise from this and was wondering what strategies are used to prevent access from unintended sources as well as means of securing data over the sockets.
Please note that the question is specifically about LocalSockets. Using other Android IPC mechanisms might solve the problem of unwanted access but sadly are not an option in my case. However, passing some form of credentials over such mechanisms can be possible if it would secure the LocalSocket.
Related
I'm trying to learn into android (linux) kernel, and I know that android needs very fast (zero-copy) IPC, but still, I don't get the reason why binder needs to be there.
Can the same thing done with unix socket + mmap /dev/shm file ?
Let's say using dbus, but to achieve zero-copy, create and open file in tmpfs (e.g. /dev/shm) delete it (so another process can accidentally open it), send file descriptor to other process and mmap it.
EDIT:
instead of create file in tmpfs, you can use shm_open too
There are mainly three reason to create new Mechanism of Binder
Complexity
Performance
Security
Complexity - In the smartphone platform, especially the Android system, in order to provide application developers with a variety of functions, this communication method is ubiquitous, such as media playback, video and audio capture, and various sensors that make mobile phones smarter (acceleration, orientation, temperature, brightness, etc.) are all managed by different Servers, and the application can use these services only by establishing a connection with these Servers as a Client
Example : MediaPlayBack -media playback, video and audio capture, and various sensors that make mobile phones smarter (acceleration, orientation, temperature, brightness, etc.) are all managed by different Servers, and the application can use these services only by establishing a connection with these Servers as a Client. It takes a little time and effort to develop dazzling Function.The widespread adoption of the Client-Server approach poses a challenge to inter-process communication (IPC) mechanisms
Performance - As a general-purpose interface, socket has low transmission efficiency and high overhead. It is mainly used for inter-process communication across the network and low-speed communication between processes on the machine.
The message queue and pipeline adopt the store-and-forward method, that is, the data is first copied from the sender buffer to the buffer opened by the kernel, and then copied from the kernel buffer to the receiver buffer. There are at least two copy processes. Although shared memory does not need to be copied, it is complicated to control and difficult to use.
Security- As an open platform with many developers, Android comes from a wide range of sources, so it is very important to ensure the security of smart terminals. Traditional IPC does not have any security measures and relies entirely on upper-layer protocols to ensure it. First of all, the receiver of traditional IPC cannot obtain the reliable UID/PID (user ID/process ID) of the other party's process, so it cannot identify the other party's identity.
Android assigns its own UID to each installed application, so the UID of the process is an important symbol to identify the identity of the process. Using traditional IPC, only the user can fill in the UID/PID in the data packet, but this is unreliable and easy to be used by malicious programs.
Secondly, traditional IPC access points are open, and private channels cannot be established.
Based on the above reasons, Android needs to establish a new IPC mechanism to meet the system's requirements for communication methods, transmission performance and security, which is Binder
i have a question in android documentation it is mentioned that android process can communicate using local sockets. does it mean that two applications with different user id can communicate using local sockets and by that "bypass" the sandbox?
It is indeed possible to do IPC using local sockets on Android, see LocalSocketServer and LocalSocket classes. These translate to UNIX sockets in the abstract namespace.
A word of warning though: Samsung has started restricting local socket use in certain cases through SELinux in their latest firmwares (unfortunately they do not use the same policies as AOSP). I'm not completely clear on the details, but I have seen instances where SELinux blocked the local socket from connecting on these firmwares. Probably depends on the SELinux context of the different processes trying to use the local socket not matching. Be sure to test that if you end up going this route.
Basic question before I get too far into coding. I was told once that in order for the Android Phone to contact a PC server, that server must be written in Java. I find this a little convoluted, but is this the case? Or by using the TCP/IP classes (Socket), can I just read and write binary data over the pipe regardless of who or how the server was written?
TCP/IP is language agnostic, you can create a client/server implementation in any language or platform that supports TCP/IP and communicate with any other TCP/IP connection.
The communication over the protocol is dependent on implementation though so you need to make sure that both client and server implementations understand the communication going over the sockets.
You can write data regardless of what kind of server it is. Whether it's written in Java, PHP, C++, or whatever does not matter. As long as the server knows how to read and write to/from sockets. I've had my Android phone connect to a PHP server today, so either my phone is disobeying the laws of the universe, or...
Also, the same applies for the other way around, it is possible to make clients for other platforms than Android to connect to a server.
I was told once that in order for the Android Phone to contact a PC
server, that server must be written in Java.
That is incorrect. The whole point of TCP/IP was to create a set of rules, a protocol to allow communication across different devices, architectures, operating systems etc.
Any TCP/IP client can communicate with any TCP/IP server period. No exceptions. (provided they implement a common version of the protocol that is)
Here I want to use System IPCs methods like
<sys/msg.h> /* SysV message queues */
<sys/ipc.h> /* General IPC definitions */
Here my android NDK code is in C language and I used message queue IPC mechanism for communication for other C application.
So please Let me know is there any way to achieve this IPC goal?
How can I implement this IPC mechanism in android NDK code?
One year ago I wrote a survey about this topic. Here is a part of it:
2 Unix IPC mechanisms
Unix IPC mechanisms include:
Unix signals.
Unix pipes.
Unix domain sockets.
At the same time Unix System-V IPC mechanisms are not included in Android.
Bionic intentionally does not provide support for System-V IPCs mechanisms, like the
ones provided by semget(), shmget(), msgget(). The reason for this is to avoid denial-
of-service [11].
2.1 Unix signals
One of the best explanations how unix signals work we can find in wikipedia: “A
signal is a limited form of inter-process communication used in Unix, Unix-like, and
other POSIX-compliant operating systems. Essentially it is an asynchronous notifica-
tion sent to a process in order to notify it of an event that occurred. When a signal is
sent to a process, the operating system interrupts the process’s normal flow of execu-
tion. Execution can be interrupted during any non-atomic instruction. If the process has
previously registered a signal handler, that routine is executed. Otherwise the default
signal handler is executed.”
It seems that unix signals are rearly used in Android programming. Moreover,
some signals have been disabled in debug mode. However, it is a possible IPC
mechanism.
2.2 Unix pipes
Pipe is a communication mechanism that allows to connect directly the output stream
of one process with the input stread of another process. There are two types of unix
pipes: named pipes and unnamed pipes. It seems that in Android programming only
named pipes are used. In this case two processes interact using a special file that
connects the output and input. It should be mentioned that pipe is one-direction way
of communication, i.e. one process is always reader and the second is always writer.
The communication file has to be created on Linux filesystem, because sdcard’s FAT32
does not allow to create pipe. Here is an example how a named unix pipe can be created
and used in Android (In Russian). The source code for this example can be found here.
2.3 Unix domain sockets
Unix domain sockets, on the contrary of unix pipes, allow to tranfer information in
both ways: from server to client and from client to server. Unix domain sockets
and unix pipes use file system as address name space. That means that server and
client use special file to establish communication. Considering Android there are two
classes that are used to program unix domain sockets: LocalServerSocket and
LocalSocket. All the implementation can be built around these two classes and it is
not required to use native code to make a unix domain socket. A simple example how
to use unix domain sockets is shown here.
[11] Android ndk documentation. NDK documentation for android-ndk-r6b
I am going to build a client-server application. The client here is an iPad (or an android-based) tablet. The server is a normal pc. Both the clients and the server are connected to the same network (using WiFi).
Is there a standard way (protocol) for communication between the clients and the server? Are there any framework that can be used to ease this communication?
Thank you
The answer depends by what you define by "server", "client", and "protocol".
Technically, the answer is "yes"; from a practical standpoint the framework you are looking for is called "socket", but regarding the protocol things may get complicated.
A protocol is a syntax structure governing data exchange, i.e., a set of rules you use to request/provide a service (see the IETF website for a list of standard ones).
Sockets, on the other hand, provide you merely a communication channel to bring bytes from one side to another and, on top of which, you are required to implement the protocol.
The good news is that socket are language independent and you can send messages between heterogeneous devices (ipad/android/linux/windows).
Using sockets in java is easy (I am making it very short here)
server side
ServerSocket ss = new ServerSocket(port);
Socket s = ss.accept();
InputStream is = s.getInputStream();
client side
Socket s = new Socket("server.address", port); // same port as above
OutputStream os = s.getOutputStream();
When you write something using os.write() the same bytes will be read by is.read().
What you write on os is the implementation of your protocol.
This topic is covered (for java language) quite well by "Thinking in Enterprise java" by Bruce Eckel, you can access the digital edition for free.
In C/C++/Objective C things are more complicated but you can easily google for tutorials.
Each service defines its own protocol and you should decide if one of the existing will do or you have to define your own, depending on which service you want to implement between the two devices.
If, as in the standard approach, the PC plays the role of server and clients want to retrieve information from it, you might want to consider installing a (very) lightweight web server and access data using HTTPUrlConnection. This is a wrapper for a socket with HTTP protocol management already implemented.
Beware, this is for Java; there is no "standard framework equivalent" for C/C++, I honestly have no idea about objective C.
Please, be also aware of the following:
If client and servers has different architectures binary data exchange may get painful, better define your protocol as a sequence of strings (like SMTP) and encode/decode binaries using base64 or some other method you may want to implement
In order to link the two sockets client has to know the server IP address; if you are running DHCP on your WIFi network then you also need to implement a discovery phase for your service
As a last side note: "client" and "server" are just labels you put on communicating entities depending on who is requesting a service/information (client) and who is providing it (server). Communication is in reality symmetrical and you can use the same structures/functions/code on both endpoints.