Options=bind needed? See systemd mailing list. They were asking why use mount bind.
Ok.
Seems like weâll be stuck with initramfs-tools forever or at least until/if all major distributions (or at least Debian) switch to dracut by default.
About /runâŚ
Older quote https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/:
- The initrd should mount /run as a tmpfs and pass it pre-mounted when jumping into the main system when executing systemd. The mount options should be mode=755,nodev
Newer quote Initrd Interface
- The initrd should mount
/run/
as a tmpfs and pass it pre-mounted when jumping into the main system when executing systemd. The mount options should bemode=755,nodev,nosuid,strictatime
.
This speaks for a initrd based implementation.
If stuck, could you please ask on systemd mailing list?
Also I guess it would be better to have only 1 place to implement mount options. Either do everything inside initramfs or do everything using systemd units. Not two places to implement. I.e. not initramfs + systemd units. Reason: lower complexity.
If going the systemd way, could you please make this configurable?
Due to high potential for regressions [1], weâll ship this disabled by default and then call for testers enabling this.
Using systemd unit files it may be possible to implement this by requiring kernel boot parameter remount-secure
being set by extending the [Unit]
section of the systemd unit file. Example:
[Unit]
ConditionKernelCommandLine=|remount-secure
Type=ext4
Is this required? Or could be auto detected? Since you like to support non-Whonix, non-Kicksecure users (plain Debian) too, this might break when users are using other file systems such as btrfs.
Type=
Takes a string for the file system type. See mount(8) for details. This setting is optional.
Therefore I guess it can be dropped and would be auto detected by systemd if needed.
[Mount]
## Uncomment this to deny execution of programs in /home.
#Options=noexec
The problem with that is that this file will be replaced once a comment or something is ever changed there in the package. Would be better to add instructions there how to do that in /etc or glaceing that file in /etc perhaps. Or maybe better, instead we could probably use:
[Unit]
ConditionPathExists=|/etc/noexec
ConditionPathExists=|/usr/local/etc/noexec
(And/or /etc/exec
/ /usr/local/etc/exec
.)
I.e. two systemd units. home-exec.mount
and home-noexec.mount
and which one is used/ignored depending on ConditionPathExists
.
filename
/lib/systemd/system/bin.mount
Must be /lib/systemd/system/bin.mount
Cannot be /lib/systemd/system/bin.mount.d
?
Filename could also be /lib/systemd/system/remount-secure-bin.mount
?
What about the mount options for the root file system /
itself?
How to test if /
is mounted with nodev
?
[1] I previously had Qubes VMs which would boot sometimes, not boot at other times or sometimes would have broken AppArmor
Bind mounts are needed because we arenât using different partitions.
No, there isnât a bin.mount in the first place so bin.mount.d wonât work.
No, systemd gives an error.
Mounting / with nodev
would break all devices in /dev
.
Checking for /etc/remount-secure would be a better implementation:
ConditionPathExists=/etc/remount-secure
Wonât work:
home-noexec.mount: Where= setting doesn't match unit name. Refusing.
In case youâre wondering why this is not merged yetâŚ
Quote Mount /rw and /home with nosuid + nodev ¡ Issue #5263 ¡ QubesOS/qubes-issues ¡ GitHub
nodev
on /home breaks qubes-builder (specifically:/dev/null
and probably other devices inside chroot). I wonder what elseâŚ
Probably also breaks Whonix build script which uses chroot in home and cowbuilder which uses chroot in /var.
Quote Environment setup â CLIP OS 5.0.0_beta3 documentation
Make sure to work in a filesystem without any restricted features such as noexec or nodev as it will cause undefined issues throughout the building process of some parts of the CLIP OS images.
The rationale of nosuid
in /home
, /run
, /dev/shm
and /tmp
(all partially user writable) is somewhat clear. Perhaps nosuid
by extension too (lower attack surface).
But whatâs the rationale of mounting /etc
and some other folders with nodev
? CLIP OS doesnât do that. Out commented by their default. I havenât seen /etc
suggested to be mounted with nosuid
, nodev
anywhere.
Maybe the argument of principle of least privilege? Well, non-root users cannot write to these folders such as /etc
by default anyhow. Only root can. And compromised root could also change mount options. Therefore I donât see any advantage of mounting /etc
with nosuid
, nodev
. Root can always create a lets say suid file in some folder (even /
). The only way to prevent that would be untrusted root / appamor-profile-everything.
Maybe a useful question to ask� Was there ever any vulnerability that would have been prevented by such mount options on such folders?
If not recommended anywhere / not helpful in any threat model, then better keep things minimal.
Yes.
Root can leave unknown suid/devices lying around.
Not with apparmor-profile-everything.
Not that I know of but we should aim to be proactive i.e. using principle of least privilege to prevent potential future vulnerabilities rather than reactive i.e. responding to a known vulnerability.
Thereâs not really any legitimate reason of having devices/suid in /etc so why allow it at all?
Kurt Seifried - LASG / Installation recommends it
Brevity.
Itâs good to be innovative. Such as in case of Whonix shipping kloak by default is a win. That threat model has been demonstrated through a proof of concept already. Proactive yes, but in this case of remounting /etc with nosuid the benefit of the change doesnât have a strong rationale.
Thereâs a huge amount of things which wonât make sense from our point of view. For example there is the hello package which most users wonât know and wonât install. I am using it as an example here. No need to pick on that particular maintainer of that Debian package. Why allow installation of that package? What if that maintainer turned evil and somehow included a backdoor in the hello package? To prevent such a backdoor from doing damage, there could be an apt wrapper that prevents installation of that and other packages which most users will probably never need. I am not supposing to invent an apt wrapper for this hypothetical scenario. It would be worse having that code than having that risk.
The superior reason from preventing untrusted root writing anything malicious /etc is apparmor-profile-everything. Once thatâs done, there is no need for an additional layer for preventive of suid creation in /etc. Many goals can be implemented in multiple ways but I donât think we should implement every goal using duplicate implementations.
For example, remount-secure all inside initramfs (supposing that is possible) would be fine. Then that shouldnât be fully duplicated with remount-secure again using systemd.
I cannot imagine any accident how any system administrator would create an suid binary and store it in /etc. And if a system administrator chooses for some reason to but a suid binary there then thereâs no need to interfere with that choice.
Itâs one valid strategy to optimize is to add safeguards for every cases no matter how likely. However, also Focus on low-effort maintainability is important which includes keeping the amount of lines of code small or even reducing it (i have some plans such as âtb-updater â binaries-freedomââŚ). By keeping the code size small itâs also more contributor friendly since more easy to understand, easier to review.
Itâs in the table there but thereâs no rationale for it either.
Keeping notes here now:
I not not sure if Mount /rw and /home with nosuid + nodev ¡ Issue #5263 ¡ QubesOS/qubes-issues ¡ GitHub is indicating that flatpak and snap also break when using nosuid on /home.
I found a rationale for /etc mounted with nodev,nosuid as well as /var. This is because some folders in /etc or /var such as /var/www are owned by other users than root. In these cases the owner of these folders shouldnât be able to create devices or suid binaries there.
New approach:
- delete security-misc
/lib/systemd/system/remount-secure.service
- move security-misc
/usr/lib/security-misc/remount-secure
to/etc/initramfs-tools/scripts/init-bottom/30_remount-secure
Details:
Script /usr/lib/security-misc/remount-secure
was probably already good enough - the only missing part is moving it to initramfs to avoid race conditions.
initramfs also uses contents from folder /usr/share/initramfs-tools/scripts/init-bottom/
(and /usr/share/initramfs-tools/
).
File name 30_
prepended because we want this to be run after /usr/share/initramfs-tools/scripts/init-bottom/udev
.
Can probably stay a bash
script. No need to port to sh
. /usr/share/initramfs-tools/hooks/resume
also uses bash
.
if [ -e /etc/remount-disable ] || [ -e /usr/local/etc/remount-disable ]; then
Does this need ${rootmnt}
? Likely not because at initramfs stage init-bottom
, initramfs already moved everything to its final place?
Kernel parameter break=bottom
might give a initramfs rescue shell which could be used for experimentation, i.e. manually running mount
commands.
Might also be possible to add command bash
followed to /etc/initramfs-tools/scripts/init-bottom/30_remount-secure
to easily get shell for experimentation.
Adding sleep 10
or so during development to the end of the script might help to easily see what the script is doing, to have sufficient time to read its debug output.
Could you try please? @madaidan
That doesnât work. The mount options are only set when running update-initramfs
. Nothing happens during boot.
madaidan via Whonix Forum:
That doesnât work. The mount options are only set when running
update-initramfs
. Nothing happens during boot.
Strange. Was it set to chmod +x
?
Then how did you implement
/etc/initramfs-tools/scripts/init-bottom/sysctl-initramfs
which is
kinda similar (as far as starts during initramfs)? Why would
sysctl-initramfs work but remote-secure not?
Yes.
Dunno. sysctl-initramfs is just writing to a few files. This is more complicated.
The actual script task, mounting might be more complicated indeed but at least the script should equally be executed? Is it a script execution issue or script functionality issue?
Seems like an execution issue. I tried simply writing to a file to check and it didnât work. Could be because sysctl-initramfs uses /bin/sh
whereas remount-secure uses /bin/bash
?
This worked with /bin/sh
although the mounts still donât.
Could very well be the reason. Although I was hoping thatâs a non-issue:
Could either port to sh
or make bash
work inside initramfs if that is possible.
Perhaps try this to easily get a shell:
#!/bin/sh
echo remount-secure
sleep 10
sh
sleep 10
The script could run mount
before and after running any actual mount
commands to see if it actually has any effect. And the sleep 10
(or more) at the end to have a fair chance to read whatâs happening. Perhaps the script is functional but then systemd or something is undoing it.