search

bluenviron / mediamtx

Ready-to-use SRT / WebRTC / RTSP / RTMP / LL-HLS media server and media proxy that allows to read, publish, proxy, record and playback video and audio streams.
MIT License
12.21k stars 1.53k forks source link

Feature request: Support customizing /dev/shm to a different path #3749

Closed samrocketman closed 1 week ago

samrocketman commented 1 month ago

Describe the feature

Description

Same as... https://github.com/bluenviron/mediamtx/issues/3748

Background

I tend to harden my OS by locking down temporary spaces with noexec (/dev/shm, /tmp, and /var/tmp).

Because mediumtx requires exec on /dev/shm to operate I need to loosen my security habits. I would like to enable an alternate tmpfs just for mediumtx in a path other than /dev/shm so that I can lock it down with noexec.

Request

Provide an option on mediumtx binary which allows customizing /dev/shm to a different path.

samrocketman commented 1 month ago

Here's an example /etc/fstab entry you can test with (failing) mediamtx

tmpfs /dev/shm tmpfs defaults,noexec,nodev,nosuid,seclabel,size=64M 0 0

You can mount -o remount /dev/shm without rebooting.

aler9 commented 1 week ago

Hello, /dev/shm is used exclusively when the RPI camera is in use and when the OS is Raspberry Pi OS, and is needed to copy and run the executable that allows to interact with libcamera and pull the video stream.

This technique was chosen since it has a series of advantages, starting from the fact that the camera process is isolated from the main executable and therefore can be restarted without handling memory leaks or crashes. It also allows us to ship a single binary compatible with all distributions, independently from the fact that libcamera dependencies are available or not, since we are starting an external process that is linked against required libraries, instead of linking the server against any library.

/dev/shm on most distributions is the only mount point that is guaranteed to be backed by RAM (shm stands for "shared memory") and on the Raspberry Pi OS it has the exec flag too.

We're not gonna change this unless we find a viable alternative.

Adding a setting for changing the folder position would mean adding a redundant setting that would be helpful to few people - if you want to go that way, you can just hack the server and recompile it.

Anyway, security is not something that can be implemented selectively - either you secure an environment or you don't. Adding the noexec folder to /dev/shm without isolating disk access or network access is of no use at all.

The standard way to isolate software is by using containers. Therefore: run MediaMTX inside Docker and it will run with a dedicated /dev/shm, disk and network space. And you will also be able to add the noexec flag to the root /dev/shm.

samrocketman commented 1 week ago

@aler9 I can harden the filesystem and provide an alternate location for the camera. I wasn't requesting advice on securing my system or asking you to not use /dev/shm. I was asking for an option to customize it.

The path is hardcoded in your program.

samrocketman commented 1 week ago

Here's where it is hard coded.

It's not a bad idea to use /dev/shm but ideally I should be able to customize it without having to recompile.

https://github.com/bluenviron/mediamtx/blob/1dfb5ba4b939521f033fffb2d304c53598b26ad4/internal/staticsources/rpicamera/component.go#L21