mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-22 04:33:28 +00:00
commit
7a6e6073a7
1 changed files with 2 additions and 2 deletions
|
@ -482,7 +482,7 @@ Sockets can be configured using `.socket` files.
|
|||
|
||||
### Writable .socket files
|
||||
|
||||
If you find a **writable** `.socket` file you can **add** at the begging of the `[Socket]` section something like: `ExecStartPre=/home/kali/sys/backdoor` and the backdoor will be executed before the socket is created. Therefore, you will **probably need to wait until the machine is rebooted.**
|
||||
If you find a **writable** `.socket` file you can **add** at the beginning of the `[Socket]` section something like: `ExecStartPre=/home/kali/sys/backdoor` and the backdoor will be executed before the socket is created. Therefore, you will **probably need to wait until the machine is rebooted.**
|
||||
_Note that the system must be using that socket file configuration or the backdoor won't be executed_
|
||||
|
||||
### Writable sockets
|
||||
|
@ -586,7 +586,7 @@ D-BUS is an **inter-process communication \(IPC\) system**, providing a simple y
|
|||
|
||||
D-BUS, as a full-featured IPC and object system, has several intended uses. First, D-BUS can perform basic application IPC, allowing one process to shuttle data to another—think **UNIX domain sockets on steroids**. Second, D-BUS can facilitate sending events, or signals, through the system, allowing different components in the system to communicate and ultimately to integrate better. For example, a Bluetooth dæmon can send an incoming call signal that your music player can intercept, muting the volume until the call ends. Finally, D-BUS implements a remote object system, letting one application request services and invoke methods from a different object—think CORBA without the complications. _\*\*_\(From [here](https://www.linuxjournal.com/article/7744)\).
|
||||
|
||||
D-Bus use an **allow/deny model**, where each message \(method call, signal emission, etc.\) can be **allowed or denied** according to the sum of all policy rules which match it. Each or rule in the policy should have the `own`, `send_destination` or `receive_sender` attribute set.
|
||||
D-Bus uses an **allow/deny model**, where each message \(method call, signal emission, etc.\) can be **allowed or denied** according to the sum of all policy rules which match it. Each or rule in the policy should have the `own`, `send_destination` or `receive_sender` attribute set.
|
||||
|
||||
Part of the policy of `/etc/dbus-1/system.d/wpa_supplicant.conf`:
|
||||
|
||||
|
|
Loading…
Reference in a new issue