Identify this new httpd / WSGI security restriction in Fedora 40

I have an internal Python WSGI script I execute from my Apache server.

This script runs a sudo command. The command executed writes some information to /root.

NOTE: Yes, I am aware of the risks — no need to comment on the inadvisability of doing this. This is a private web-server with very restricted access.

Prior to Fedora 40, this worked without any problem. However, now on Fedora 40 when attempting to write to a file /root/foo, I get:

/usr/local/bin/my-command: line 8: /root/foo: Read-only file system

Outputting findmnt within the context of the running process shows that indeed the filesystem is viewed as read-only from within the WSGI script context:

TARGET           SOURCE                                    FSTYPE          OPTIONS
/                /dev/mapper/vg_raid1-lv_root              ext4            rw,noatime
|-/root          /dev/mapper/vg_raid1-lv_root[/root]       ext4            ro,noatime

So this seems to be some kind of new security protection. Can anyone tell me what is happening here / point me to some docs on this?

Can you check your /etc/fstab just to make sure? This one has me puzzled, and i don’t see anything in the Fedora 40 Release Notes

1 Like

The httpd.service systemd unit now has a lot of hardening options set, which includes ones like ProtectHome=read-only that causes /root to be mounted read-only and also RestrictSUIDSGID=yes which will likely stop sudo from working.

You can use systemctl cat httpd.service to see the full configuration, and systemctl edit httpd.service to create a drop-in to override some of the options if you want to relax the sandbox restrictions.

3 Likes

PrivateDevices=

:laughing: Pretty cool IMO, but that should have happened a long time ago. This would mean something changed along the line since OP mentions not having this issue before.


From the man systemd.exec

 ProtectSystem=
           Takes a boolean argument or the special values "full" or "strict". If true, mounts the /usr/ and the boot loader directories (/boot and /efi) read-only for processes invoked by this unit. If set to "full", the /etc/
           directory is mounted read-only, too. If set to "strict" the entire file system hierarchy is mounted read-only, except for the API file system subtrees /dev/, /proc/ and /sys/ (protect these directories using
           **PrivateDevices=**, ProtectKernelTunables=, ProtectControlGroups=). This setting ensures that any modification of the vendor-supplied operating system (and optionally its configuration, and local mounts) is prohibited for
           the service. It is recommended to enable this setting for all long-running services, unless they are involved with system updates or need to modify the operating system in other ways. If this option is used,
           ReadWritePaths= may be used to exclude specific directories from being made read-only. This setting is implied if DynamicUser= is set. This setting cannot ensure protection in all cases. In general it has the same
           limitations as ReadOnlyPaths=, see below. Defaults to off.

           Added in version 214.

I didn’t just make it up you know - try comparing the systemctl cat output between Fedora 39 and Fedora 40 if you don’t believe me that it is a new change…

1 Like

I guess there’s just too many things to detail in Release Notes. What I found digging through the man pages is that it’s been in there for a while. Added in ver 214

Oh systemd has supported many of them for a long time but they’ve only just been added to the httpd service.

2 Likes

So I guess you can modify the service unit file and set PrivateDevices= to false might get around this kind of implementation ? If the OP has such a thing?

[Service]
...
PrivateDevices=false

Thank you, setting ProtectHome=no solved it!