Secure Remount Without Remounting At All For The Most Part - Secure Mount #165
Conversation
|
Actually I also took care of the ones that can't be overriden as well, just now. Untested, but should work. We only and only remount 2 things, |
monsieuremre
changed the title
usr/bin/bind-directories
Outdated
|
|
||
| if ! findmnt "/var/tmp" | ||
| then | ||
| mount -o defaults,nodev,noexec,nosuid --bind /tmp /var/tmp |
There was a problem hiding this comment.
/tmp /var/tmp
This is a a bug? /tmp and /var/tmp have different purposes as per FHS.
There was a problem hiding this comment.
This is not a bug. It is intentional.
Normally on servers and professional deployments it is not uncommon to have /var/tmp as a seperate partition. This aims to prevent /var/tmp being filled arbitrarily and stop /var from functioning by physically throttling space. On desktop computers, a seperate partition is for the most part unnecessary and costs valuable diskspace.
Binding /var/tmp to /tmp addresses this issue on systems that do not want to dedicate the disk space but still want to have the extra benefit of not risking to throttle /var. It is not uncommoon practice to bind these two and mount them on ram in high security environments.
It is recommended to do this by CISOfy, if /var/tmp is not on a seperate partition. See:
CISOfy - Lynis
https://github.com/CISOfy/lynis/blob/master/include/tests_filesystems
Test : FILE-6376
Description : Bind mount the /var/tmp directory to /tmp
It also makes sure the secure mount options are applied to this section as well without having to bind to itself. Temp files residing in tmpfs is also a security benefit for the desktop user. It should bring up no complications or breakages.
There was a problem hiding this comment.
This could use a comment with a few links to references (most not being big source code files).
usr/bin/bind-directories
Outdated
|
|
||
| if ! findmnt "/boot/efi" | ||
| then | ||
| if [ -d /boot/efi ] |
There was a problem hiding this comment.
So /boot/efi isn't a mountpoint but then check if /boot/efi is even an existing directly. But if this is a thing then this test -d (is directory) should consistently used everywhere....
There was a problem hiding this comment.
Better to use function remount_secure (modified) from /usr/bin/remount-secure?
- It checks if it's a mount point.
- It checks if the folder exists.
- Has debug output.
There was a problem hiding this comment.
So /boot/efi isn't a mountpoint but then check if /boot/efi is even an existing directly. But if this is a thing then this test -d (is directory) should consistently used everywhere....
I had the same thought but then concluded, no. This is the only thing that might not exist at all. For everything else, checking directories is comletely superfluous.
For examle, if there is no partition for /boot, then /boot is a directory on the root pratition. There is no other possibility. So it is totally unnecessary to check if /boot is a directory. Because it is. It has to be. If it is no partition, then it is a directory. No system can exist without it.
/boot/efi is the only exception here. If there is no partition for it, there is a good chance it might not exist at all. Because it is not universal in the same sense. It exists only in UEFI system. If a system runs on legacy BIOS, there won't be /boot/efi. So here is the only place it makes sense we check if this directory exists at all.
Normally /boot/efi is almost always a seperate partition on UEFI systems because it has the vfat file system. Since most linux installs default to ext4 or something else for the root partition, they do a seperate partition for this. But it seems also possible to have everything in vfat and not use anything else, thus not having a seperate partition for /boot/efi but rather having it as a directory. This is why we check, for this possibility.
There was a problem hiding this comment.
It's a very valid use case to have a system without /boot.
(KVM Linux host operating system provided direct kernel boot, a Linux distribution such as Kicksecure inside a folder (chroot) using systemd-nspawn, OpenVZ probably and others)
|
Not sure yet. Many points to consider... |
|
As per this PR, the short summary:
Please correct and write a better one if I am wrong. |
|
At this stage with so many discussions scattered around various issues and PRs it would also be a highly useful contribution to have developer documentation summarizing all the various options and approaches as it gets increasingly convoluted and hard to reason about it. Could be added here: |
|
How is this PR better than...
This PR has systemd mount files, which is a nice approach in theory. But it gets harder to understand because in addition to the systemd mount files, two other mechanisms have to be used:
This makes it a lot harder to understand, predict what's happening, explain to users how to customize. In practice, the systemd mount files would do little because the default fstab generated by grml-debootstrap is rather minimal. Therefore "lots of other stuff" is going on in /usr/bin/bind-directories, namely
In addition to that there's also /usr/bin/remount-api with an almost duplicated systemd unit. Therefore I am asking, how is this PR better than the existing /usr/bin/remount-secure implementation? It can handle all of the above mentioned mount points and in addition to that has the following advantages:
Why not use systemd mount files for everything including bind mounts? This article says it's possible: Could it be an issue that we don't know if it's a dedicated mount point or just a folder? Could this be phrased a missing systemd feature / feature request? In that case, please point to or draft/write a systemd feature request. Let's take for example /var.
The existing /usr/bin/remount-secure implementation would handle both cases, X and Y. This PR would as of now only handle case X. [1] These features could be dropped / replaced by consistently using systemd mount files for everything. [2] |
A yessir you summarized very well.
First and foremost: it jumps no hoops. The existing solution remounts everything. This on its own:
This solution here is:
They only resemble each other when it comes to remounting For binding directories, they are the same in outcome but definetely not the same in functionality. The older implementation is designed to remount things and maybe bind them on demand, has more complexity. This one is much simpler and just bind the directories. The remount-api is also very, very simple. And I see there is some misunderstanding here so let me clear it.
No. This is not a problem. You explained correctly what the old implementation does. So let me explain what my new implementation does. Let's take for example /var. I think you can see the difference. We don't take the effort to remount it or whatever. Because we know that it mounts with the correct options anyway, in the first place. What we check is if it is a directory, we bind. That's it. We do nothing because when systemd generates the mount units using fstab, our config files come on top of those units and make sure the units have hardened options in the very start. On our end, we can literally also do nothing and everything will be mounted securely. Binding stuff is just something extra we do for directories. So in fact, I'd say the implementations are vastly different from the ground up. |
|
And also, I can split this pull into two so that the config files are merged first, because they are literally just files and don't execute anything and cannot possibly break anything. The remounting of only /dev and /dev/shm and binding of non partitions is also still considerably faster/simpler in comparison. |
|
note to self:
|
|
To re-iterate my question from above (see with more content surrounding it):
|
|
And I did exactly that. I tested the following scenario: There is a /home partition, there is no /var partition. Mount units for home and var are created as they are here under /usr/lib. What happens:
So just as we want. The others I haven't tested just yet, but I see no reason we can't generalize this result. No script no exection no nothing. |
|
Done some big research on how we can handle /dev and /dev/shm. And turns out, there was a fstab.d in the past. It was added to util-linux, but was reverted afterwards. See here. The --fstab options supports defining more than one fstab files. Fortunately, I found a way to not remount anything. Everything will be mounted securely. And I also a found a way to define a file to add to the existing fstab dynamically. Unfortunately, I actually didn't because it requires systemd version 254, and debian bookworm ships with 252. But apart from that, the solution is there. What we do is, we set the following kernel parameter: And that's kinda it. Now, since we can't do this because of the version, I am looking for another solution. By the way source: https://www.freedesktop.org/software/systemd/man/latest/systemd-fstab-generator.html Edit: looks like we have to keep the remounting of these two just for now. |
Or ConditionPathExists ConditionPathIsDirectory or similar as per https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#ConditionPathExists= as mentioned in a prior ticket or PR.
As mentioned, these 2 can remain an unfortunate exception. I.e. after exhausting asking upstream(s), if impossible, it is ok that remount is used for these.
Please draft for or ask systemd-devel mailing list. |
|
Wrote my comment before reading your follow-up comments and new git changes. |
|
So this is starting to look very nice.
Could you please rename all |
|
Other todo: testing. Please let me know once this is tested. Readme:
|
Yeah sure. Better done after merging tho, since things might change on the go. It is because what takes precedence over what. |
|
I'd also like to see: but I could do that after merge. (The exact name of the kernel parameter can be discussed.) This is to make it simple to test this with/without and to make it easy to disable all of this in case there are unpredictable issues. |
|
The thing is, I haven't even tested the command line parameter yet on debian sid. The documentation makes it seem like it will work for sure. And I am not really motivated to test just yet. First I want to tackle it in the current version. Then for the next releases it might just become even cleaner. When it comes to remount. /proc is also an api file system. I want to remount this one too, but with hidepid=4 and all the good old options. I think we can merge the existing hidepid service inside this one to reduce the number of services. Should I proceed? |
|
When it comes to remount. /proc is also an api file system. I want to remount this one too, but with hidepid=4 and all the good old options. I think we can merge the existing hidepid service inside this one to reduce the number of services. Should I proceed?
This can be done later after this one was tested and merged. It already
has its own dedicated ticket.
Not mixing too much stuff together which has potential for breakage.
|
|
Ok. The drop in configs under /etc work perfectly in any case all the time and they make sure every partition is moutned securely. The same can't be said about bind units. There are some certain problems. Double mounts are unavoidable with /var/log. I think we shouldmerge the first part now, since it works. The bind and /dev /dev/shm, I will handle seperately. Does this sound ok? |
|
No, I don't want to mix two different approaches, that is systemd drop-ins for partitions mixed with shell scripting for bind mounts. Too complex to understand, document, customize. The current implementation (remount-secure systemd unit and script) is less complex and covers all. But even that is non-ideal. After all the time spent on this topic, all issues and corner cases with all the hacks that aren't directly shipping a hardened /etc/fstab by default I think that #157 (i.e. fixing this issue at the root in image creation tools / installers such as grml-debootstrap / calamares) seems the most promising, stable, simple. |
|
Well this is the day. At last. Today we harden them all, no remounting at all, not even I found a way to implement a quasi fstab.d manually. Very easy, works, and it is epic. I tested it too. Here are the steps:
We do not touch or own the old
Would this be a desirable option? I did a lot of research and I can tell with confidence that it won't get any better than this probably. |
|
That is for sure an interesting, clever approach but maybe not the robust, stable and perhaps boring (?) implementation I am looking for.
The mostly minimal kernel command line modification is nice to avoid bloating it even more as the other security-misc kernel parameters are already expanding it a lot.
But aren't these controlled by systemd unit files too?
Hook? Dracut hook? (Implementation detail: The "generate our fstab" script should be separate so it can be easily run/debugged.
For
This is good.
It seems to me you're into an intellectual challenge, i.e. like to solve complex issues by coming up with more complex solutions but I am confused why #157 (comment) is continuously ignored. I don't think a better solution can be found than shipping a hardened by default /etc/fstab in newly built Kicksecure images. That seems the most simple and robust solution. |
I skip over this one because I would rather have this package universally harden the mounting options even on a debian install. And I think this is possible too.
Init hook. Not depending on dracut, more preferably.
Now, I hear your point about messy fstab generations. But I have to disagree. This is no more messy than having mount units, in fact less messy I would say. We can do this:
By this we achieve:
Now, we just have to handle binds. For this we can parse the old fstab and add the necessary bind lines dynamically. This won't/can't be messy. Because fstab already has a predefined format. Parsing can't go wrong. And after that, we just add extra lines, which also can't go wrong. I think this one you would be more accepting. I eliminated the modification of lines completely. There is just adding new lines left. What would you say to this option? |
And that's where I am different as a maintainer of this package. For me, security-misc is just part of Kicksecure. My primary goals is to have well maintained projects Kicksecure and Whonix. It's nice and good, clean, solid design if security-misc can be used on Debian. That allows using it on other Debian derivatives and makes it easier to port to other Linux distributions too. But if things can't feasibility be solved directly upstream (in Debian or software packages by Debian developed by third-parties) (which is always the best because then Kicksecure doesn't need to carry a delta), then the improvement can be carried in Kicksecure, if feasible. But not necessarily in security-misc if that isn't feasible either. feasibility is related to the time effort required and also means it must be maintainable. In this case, hardening mount options seems simplest to fix upstream (grml-debootstrap, Qubes, calamares). No impasse has been reached with upstream yet. I am always trying to discuss, fix things upstream first so no delta needs to be carried in Kicksecure and the security hardening benefits as many people as possible (then there's also multiple eyes on implementation, documentation, support and bug fixing). The next best implementation and still very easy to understand, robust solution would be shipping a hardened /etc/fstab by default for newly built Kicksecure, Whonix images. [1] So I've pretty much settled on that solution. Anything else seems to create a lot (potential) follow-up issues. Looks easy at first but the devil is in the details. harden-module-loading.service broke the boot process. It's interesting, might be useful for some servers. But since it breaks the boot process it cannot become the default. It's opt-in nature limits its usefulness. #147 broke the build process in multiple ways, took many hours to research and fix. Was worth it and now hopefully stable. But as for hardened mount options, anything other than a hardened /etc/fstab seems a multitude more complex than the mentioned broken things. [1] Upgrading existing images is possible too. Implementation detail. Not difficult but harder to explain than do. |
|
Alright. Then closing this one. I suppose the old remount secure service should be removed from the package and the readme as well in this case. |
|
I want to re open this pull. There was only one little thing that was preventing this branch from working completely and only with drop in config files, and that was the api file systems like I have to say, this option is too good to discard. It is compatible with all fstab files and all partitioning schemes. There is also no work done on our end, just some lines in some files. The newer systemd versions allow filling the last missing part. Normally, we can already achieve these:
Our missing piece was:
Our missing piece is possible with a kernel parameter. I say this. Speed is of essence. Let's do the hardening. Any time there is a choice between uncertainty in the future vs. certainty now, we gotta choose now. I want to re-open this request if you are willing to take this path @adrelanos. |
|
The branch was deleted by you so I cannot use the reopen button. |
|
I will restore the branch. Are you open to this idea of using config files only and being fully effective after the next debian release? If you say it might be 'considered', that would be enough for me to restore the branch. But I do not want to create a distraction if you are certain this is not way you want to address this issue. |
|
Yes. |
|
I've done some contributions to the wiki. To some various pages including this one. If there was a way to make wiki contributions doing a pull request here, it would be easier to manage and easier to track. I don't know how difficult this would be to implement, it's just some unrelated feedback that you might consider. |
Ok good. Soon when I find the time I will restore the branch, check everything again and reopen the pull. |
MediaWiki content fortunately doesn't have first class support for git integration otherwise I would be all over it. As a user of both, MediaWiki and git this is on top to my tooling wishlist. To have git based updates and also have a bridge for those who prefer to edit locally, use git branches, pull requests, etc. There's git-mediawiki but not well maintained last time I checked so that unfortunately broke. related: |
That was done with #195? A bit confusing to have a new pull request. |
|
Yes absolutely. The new request is literally the same content so practically the same as restoring the branch. I did it for it to be more clean. |
This here. We don't own fstab, we don't modify fstab, we don't modify any files at all. We just add our own little config under respective directories. For var for examle under
var.mount.d. This targets the real partitions on disk. If there is literal partition for /home, when mounting it systemd gets everything from fstab, our options come on top of everrything afterwards. If there are no entries in fstab, so no partitions on disk, these overrides simply don't serve any purpose and are never read, so they do no harm. This makes sure we directly mount all partitions in fstab with the secure options in the first place. So no remounting occurs at all.For directories that don't have their own partitions, we bind them. Still, no remounting. We bind these and we are done.
So overall very good. The only caveat is, we can't apply our extra options for
/run,/devand/dev/shm. These can't be manipulated with mount unit overrides, they need to be addressed in fstab.Cannot create mount unit for API file systemFor these we have to find another solution, which is unfortunately going to be remounting probably. But for now, let's get everything else on board first. This solution covers everything and jumps no hoops. Everything is hardened from the beginning.
Please test. Also the old implementation has to be deleted before merging this.