Artix Linux Forum

Shared memory mounted read-only

23 April 2021, 22:38:22

Hello, i came across an article claiming that mounting shared memory in read-write mode can be dangerous and prone to exploits, quote "Because two or more processes can use the same memory space, it has been discovered that, since shared memory is, by default, mounted as read/write, the /run/shm space can be easily exploited" Later in the article they say mounting shm in read only mode can cause some problems though ex. google chrome. What can go wrong in artix if we mount shm in read-only mode if we don't use "ever" chrome. Another option less restrictive is "mount the shared memory with read/write access but without permission to execute programs, change the UID of running programs, or to create block or character devices in the namespace". If anyone know more about this aspect i would be very happy to hear your thoughts.  . Thanks in advance in case anyone can tell more about this one

P.S. source is techrepublic

Re: Shared memory mounted read-only

Reply #1 – 24 April 2021, 00:49:20

I have no idea what article you are referring to, but tons of programs will of course use shared memory and need write access to /dev/shm. I'd expect tons of things to break if that is changed.

Re: Shared memory mounted read-only

Reply #2 – 24 April 2021, 09:00:37

Thanks for the advice this is the article

Re: Shared memory mounted read-only

Reply #3 – 24 April 2021, 10:01:31

Shared memory is a fundamental concept of Unix and Unix-like systems. Specific bugs can be dealt with, but you don't just entirely dismiss such a thing as shm.

Re: Shared memory mounted read-only

Reply #4 – 24 April 2021, 12:45:11

The shm is not dismissed entirely just mounted read-only or the second less harsh version with read/write but without executing stuff from memory.

Re: Shared memory mounted read-only

Reply #5 – 24 April 2021, 20:41:25

The article is talking about servers in a data center which may use a limited and fixed number of apps, and suggests you simply test if it works on the installation in question.
But this may be relevant:
https://forum.artixlinux.org/index.php/topic,1830.0.html
That shows there have recently been changes to virtual memory file systems in the kernel to make them more restrictive by default, after that article was written. Possibly they mitigate these exploits - I don't know but it seems potentially linked, there must have been some reason for the changes.