Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am currently working on interprocess communication, and I am struggling to find information on this topic. How are interprocess communication secured (for internal communication, not over network sockets as an example) ? I am asking this question for any IPC (pipes, shared memory, ...).
Is there access rights defined between user process communication ? Is there an integrity check, or encryption ?
For an IoT that would use embedded linux, is there any point in implementing security for a homemade IPC protocol ? If the external interfaces are secured, then the IPC should not be exploitable for someone without at least user level of privilege access ?
Thank you for reading this topic and answering if you have some knowledge on the topic
Shared resources use the same security model as files e.g. man ipcmk - hence no specific mention. If you want anything on top of it - encryption, etc, you have to do it yourself, again, as with files.
yes, it depends on you. If you want to send any information from A to B you need to protect it. (it is [almost] irrelevant if you use bluetooth, wifi, network, ipc or any other kind of communication).
Thank you all for your answers. External interfaces such as Bluetooth, wifi, etc will ofc be protected (encryption, and for back end communication TLS for authentication). I want to focus on the internal communication of processes (for an IoT, one process responsible of external communication communicate internally with an other process responsible for making the IoT fulfill its mission).
From your answer Dugan, it would seem that access control is sufficient for IPC, but I would like to understand why is it necessary?
Ivm when you say they use the same security model as files, it is basically access control ? You define who can access which IPC ?
Yes for a multi-user space I understand. But in the case of an IoT device where people won't actually have a linux account (they will just interact with the object, but that is it) would you consider it necessary ?
You need to protect it if there is any way (possibility) to log in or execute anything (remotely) on that device.
Otherwise you don't need to care about it.
The level at which a device of any specification can be secured for the most part depends upon the amount of processing power and memory. These two metrics get progressively more pertinent when you start adding more and more complex levels of encryption ciphers. This is a problem because you're probably going to have limited access to the device once it is deployed.
To make the above determination we need the specifications of the SoC or embedded device that you planning to use for this operation so that we my further assist you in the trouble shooting and recommend a further path forward.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.