systemd has options to sandbox service daemons. This means, for example, you can block a daemon from modifying anything in the /etc or /usr directory, and also it can make the whole /home directory invisible to that daemon. And much more. Try run the command systemd-analyze security and then for example systemd-analyze security systemd-resolved.service. This is rarely mentioned except in the systemd documentation files.
3 Likes
Villy’s post reminds me (for unknown reasons) on another means:
noexec, nodev, nosuid → mounting file systems with theses
parameters increases security (you can set them permanently in
/etc/fstab).
However, unless you have a system that offers only a very limited amount
of binaries (which means, no access to any binaries like interpreters
and terminals), noexec is widely useless (while it sometimes breaks
things). This means, in most cases you can forget it, and thus Fedora
does not use it as well in most cases. But temporary file systems and
temporary mounts are mounted with nodev and nosuid by default.
Yet, if you have fstab-mounted devices that an attacker could have
access to (e.g., external disks which are physically accessible by
others and which are mounted nofail because you don’t have them always
with you), it might make sense to use all three parameters when mounting
them (noexec, nodev, nosuid) to increase mitigation against
manipulation capabilities through these devices (this goes already
towards exploiting any little security means to achieve implicit security).
nodev, nosuid are most valuable if you ensure that all devices, on
which the untrusted users have any type of write access to, are mounted
with these two parameters (nodev, nosuid). But you have to be aware
that this means that you make /var a separate partition. This is
easy within Anaconda (already at this time): you can just create an
automated partitioning with btrfs, and then just add a separate /var
partition. When you have chosen a btrfs configuration, Anaconda
automatically puts the separated /var as subvolume inside the btrfs so
that you do not need to care about storage allocation (all btrfs
subvolumes share the btrfs storage). Other reasons for separating /var/
etc. shall be less relevant on end user installations. It can make sense
to also mount /boot with nodev and nosuid (I am not sure if that is
already done by default atm).
Nevertheless, be aware that nodev, nosuid in /var can cause
trouble and may break some applications! You have to test if you are
affected, and keep that fact in mind when you add new applications in
future. But if it does not work, you can just remove the parameters
again and reboot. So testing ain’t dangerous or so. E.g., at the moment,
toolbox is broken with any of the three parameters. However, this is
likely to change with one of the next releases so that nodev, nosuid
should become usable with it in some time.
That said, these means do not add so much security and Fedora (and most
Linux distributions) achieve their security by other means. The value of
these parameters has decreased over time, but when you put them in place
where they do not create trouble anyway, they remain a well complement
to annoy attackers 
Important: do never add these parameters to devices with
system-related folders (except /boot, /home and /var as elaborated
above)! This won’t work at all
1 Like
However, unless you have a system that offers only a very limited amount
of binaries (which means, no access to any binaries like interpreters
and terminals),noexecis widely useless (while it sometimes breaks
things)
There does seem to be some work being done on that front by Microsoft → Microsoft Aims For Greater Script Execution Control On Linux - Phoronix
I do not want to engage in a firewalld discussion atm, but I would
like to ensure that we are all on the same page about the implications
of firewalling and ports:
There are source and destination ports. Both are not equal in a
connection. This is very important: if you access Wikipedia with your
browser, you maybe know that the port 443 (standardized for HTTPS) will
be used. However, this is only the destination port at the Wikipedia
server. Your browser chooses one of the non-standardized ports and
blocks it for the very connection (e.g., 4444), which is your source
port. Wikipedia then answers from HTTPS to your 4444. This behavior is
not a decision of Fedora but standardized on the Internet.
443 and other standardized ports are blocked by default on Workstation
and KDE Spins (I guess also on Silverblue/Kinoite; but at least in
the past the netinstaller was blank in this respect) so that
applications cannot abuse your system to provide standardized services
on the Internet and/or keep listening to them, which may cause trouble
to you and also involve your installation in activities that are maybe
harmful to others (causing legal issues for you or so). This limits the
use of ports for untrusted users to non-standardized ports, which have
less possibilities for abuse.
Therefore, if you block the non-standardized ports at all, even web
browsing or checking emails will no longer work. On the other hand, if
any of them is open, there is the possibility for applications to use them.
Furthermore, be aware that although the firewall allows applications to
block and then use the non-standardized ports, there needs to be an
application from inside to block and keep the ports open before anything
from outside can send something to them. This is not just achieved by
the firewall but also by the kernel itself, which also is a major means
of abuse mitigation in these realms (you may view the mitigation
behavior of both in conjunction).
Firewalling is a more major security means on installations that
provide services, but on end user installations that use
services, its value (in combination with related kernel means) is
primarily to achieve two goals: first, avoid that any process from
inside can provide standardized but unintended services to (and listen
on standardized ports from) outside. Second, nothing from outside can
create a connection to the system unless this connection was requested
from inside. Both is achieved in the current installations from the
Workstation WG and the KDE SIG. On end user installations that use
services, firewalld is just one of many security means. When it comes
to avoid unintended applications at all and/or to restrict their
privileges/access to data, other means are more important than the firewall.
You may note that the WG/SIG wanted to avoid events like that after the
introduction of SELinux (long ago), where services/applications did no
longer work while many users were not qualified to properly adjust
SELinux (or didn’t understand the issue at all), so that average users
got annoyed and simply disabled SELinux (or in this case, the firewall)
at all.
That said, if you provide services locally on your system that are
accessed through web protocols (e.g., cockpit web interface), it might
make sense to increase security by blocking the one port used by, e.g.,
cockpit (I think 9090). Usually, most such applications should by
default reject connections except localhost unless they are configured
manually to accept more than localhost, but when blocking the respective
port, you ensure explicitly to disallow access from outside and reduce
attack surface. This will not cause trouble to other applications
(browser and so on), which do not rely on any specific non-standardized
port.
2 Likes
Interesting! Thanks for sharing
You may be interested in this new upcoming project!
Flatpaks are working now, as bubblewrap-suid is built on COPR and added.
Podman and relevant tooling like Toolbox or Distrobox are not yet working due to disabled user namespaces, but with some fix this may work