# DistributedIPC

**Repository Path**: distributed-access-control/distributed-ipc

## Basic Information

- **Project Name**: DistributedIPC
- **Description**: Distributed capability-based IPC framework.
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2021-02-22
- **Last Updated**: 2021-08-31

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# DistributedIPC
本项目的目标：实现AA/FA的权限规则配置和检查。设计一种可描述跨设备强制访问控制规则的DSL，在兼顾解析性能的同时有足够的灵活性，在富设备和弱设备上都能解析运行。并且
能够配置跨设备的访问规则，例如：配置本地的。  实现LocalApp到RemoteApp之间的强制访问规则的配置，而不需要关心具体使用的通信协议和端口。

例如：我们可以给一款IoT设备配置其中哪些。例如，规则一个弱设备只能连Huawei云，和huawei中枢。这里的配置实现了将IPC访问和设备认证绑定起来：
```
device_metadata {
    SELF_DEVICE_TAG = LITEOS_DEV
    Capabilities = {INTERNET, HUB_CONNECT, APP_CONNECT}
}
default_process {
    use IoT::BaseProcess
    endpoint {
        Tags {allow @TAG{HUAWEI_CLOUD}, @TAG{HUAWEI_HUB}}
        Host {allow @URL{"https://iot.api.huawei.com"}}
        PORT {2350-4000}
        MAC {}
    }
    filepath {
        allow @{PROC}/data/* RW
        deny  @{SYS}/*       MRWE
    }
    accept_porcess {
        device {
            TAGS {allow @TAG{HUAWEI_HUB}, @TAG{HUAWEI_MOBILE}}
        }
    }
    Capabilities_Require {

    }
}
HiLinkProcess {
    // ...
}

```
注：这里只是一个示例。正式版本应该会基于Lua语法或者TOML等轻量级解析语法进行配置。


涉及到的Demo场景有:
- 富设备（Android,TV，中枢） 到 富设备。  
- 富设备（Android,TV,中枢）到 弱设备。   

本项目一共包含三个demo：  
- DistributedIPC（当前）
- [linux-packetverify](https://gitee.com/distributed-access-control/linux-packetverify) ，解决Linux设备的包认证
- [iot-packet-verify](https://gitee.com/distributed-access-control/iot-packet-verify)，解决IoT的包认证


## 设计
我们针对跨设备IPC场景，通过Local App(Process) <-> Local Port之间，以及Local Port <-> Remote Port，以及Remote Port <-> Remote App的绑定，其目的是让本
地应用和远程应用的IPC Channel是绑定的，例如：远程的22端口对应的一个本地的ssh IPC，我们的机制能保证只有本地的ssh才能向远程的22端口发合法的数据包，本地设备中其他
应用无法利用这个端口发数据，设备外的其他应用无法利用信道劫持的方法向远程的22发数据。从而

分为以下模块：
- reference monitor，
- 跨设备的连接权限认证，


### Reference Monitor模块  

Reference Monitor作用是维护全局的Object之间的访问关系，并提供权限检查API，例如：  
```
type reference_monitor {
	register_remote_app(); // 完成设备认证以及验证 app 权限  
	check_app_permission(); // 从cache中读取 app 权限校验
	check_api_permission(); // 从cache检查 API 权限
}
```


### 跨设备的连接权限认证  
主要目的是打通本地的Process PID到远程Port以及Remote PID的绑定。通过包的Token签名认证，让远程的Port只能被本地的被授权的应用使用。
这样能确保远程的应用的端口只能被指定的App使用，攻击者无法从任何位置（local device, off-the-path, remote device）发包进行IPC劫持、篡改和重放攻击。

Per-Packet verification部署：  
1. device之间的peer-to-peer的连接：   
由设备层内核之间进行认证。   

2. device-to-server的连接：  
对于server连edge-device，由于server端存在负载均衡，实际的tcp收包服务器和TLS解密服务器是最外面的nginx服务器，由nginx转发给内部的mqtt或者coap服务器。
因此packet-verification需要部署在gateway server。此时由gateway完成设备认证和再和device进行包认证。


## 实现