Mount Secure

[monsieuremre]

Good old mount secure that works with all systems and configs.

Only downside: no bind mounting when no partition on disk. We can actually do this, but before it, we have to make sure that there is no dediated partition for what we want to bind. So if there is a way to determine that within kernel command line, we can also bind mount things.

[adrelanos]

Determine from kernel command line if there are partitions or not? I don't think that is possible. Kernel command line can only declare settings. Does not support scripting. It cannot figure out things.

This is https://www.kicksecure.com/wiki/Dev/remount-secure#Systemd_drop-in_mount_options_for_units_that_already_exist?

[monsieuremre]

Determine from kernel command line if there are partitions or not? I don't think that is possible. Kernel command line can only declare settings. Does not support scripting. It cannot figure out things.

Yeah thats what I thought. It is just a comment. Binding things is the only part that is not covered. To be honest, I don't think binds are a stable feature with any implementation. I can create bind units that will not come into effect if there are partitions. This would cover bind cases. The only downside is, it won't cover nested binds. So we will bind home and var and stuff, but we won't bind /var/tmp. This would still be a massive improvement tho. I can add this if you want. The reason why we can't cover nested binds in this manner is, I have tried and there are always a million conflicts, and even if you fix them, they reoccur if anything ever changes. Unnested binds create no issues tho with units.

[adrelanos]

This is a re-vitalization of https://github.com/Kicksecure/security-misc/pull/165?

This is https://www.kicksecure.com/wiki/Dev/remount-secure#Systemd_drop-in_mount_options_for_units_that_already_exist?

[adrelanos]

Note to self (maybe): The 50_ file prefix is usually reserved by users by convention in Kicksecure. Not a big deal. I could rename these if this gets merged.

[adrelanos]

Only downside: no bind mounting when no partition on disk.

Binding things is the only part that is not covered.

That is a major, major downside. Because distributions using security-misc (Kicksecure, Whonix) (short: derivatives) will not use separate partitions for the foreseeable feature as this is hard to implement. So the benefit for derivative Linux distribution users will be rather minimal. Only for those few that manually set up separate partitions.

---

API file systems secure mount options looks nice, clean, is probably fine and mergeable. Didn't test yet. You?

---

I am actually not comfortable to merge remounting of separate partitions only. Then the noexec usability issue would only apply to the fewest users, which would be confusing during user support.

It could be merged but then commented out by default so this feature gets more visibility and those who want it can opt it in.

I would be more comfortable if there were automated (CI, github actions) based tests which can be used to confirm that this does't break the boot now or later. This is even hard to test for me because I am not even myself using separate partitions yet.

The main point of hardened mount options is this to be functional for Kicksecure users. The very few, very advanced users using separate partitions already (even not a Kicksecure default (yet?)) aren't a priority. So these cannot get this feature first because I myself have issues of testing this, let alone to sign up to keep testing, maintaining that this doesn't break. Even Debian installer doesn't set up separate partitions by default.

So the main focus please needs to be something that would actually get used by Kicksecure users.

Don't we have any more promising way on https://www.kicksecure.com/wiki/Dev/remount-secure? -> Ticket: https://github.com/Kicksecure/security-misc/issues/157

[adrelanos]

-> https://github.com/Kicksecure/security-misc/issues/157#issuecomment-1938753325

[monsieuremre]

The reason I don't have the bind mounts is not that we can't have them. We can. We can set the mount units and boom everything binds. We can set conditionals too. But I am more skeptical of this. Because I think bind mounts are very non optimal. It is basically a workaround that may or may not work depending how early you do it. Doing it with a script or hook is like, fine but reall impossible to configure. Fstab is also equally impossible while staying a package.

If we absolutely want bind mounts, these should be checked all the time dynamically. We have some daemons. I have written some draft of an idea that I have. I will write it to completion for your review if you find the idea reasonable. This would, however, split the current package's content into two.

We have the same problem with file permissions, als ohiding the hardware, also hiding kernel information etc. A lot of stuff has to be done regularly and dynamically. Having systemd services run scripts is really slow solution that is not only non optimal, it is also non universal, as different shells might behave differently, and processes are unsafe by nature and can be manipulated by the user or even other services willingly or not.

I think we should approach bind mounting with a daemonizing solution. For security misc, there can be one daemon to do the menial work in the background. This would include, I imagine

• Hiding hardware
• Setting file permissions
• Making sure mounts are safe

This daemon has to be thread optimized and fast and therefore a binary. I have written a draft in rust. Because rust is epicly fast like c but also memory safe and thread safe and all the stuff. This daemon listens to file events. If file permissions change, it checks if the affected file is protected by it, if yes, it reverses the file permissions to the secure default. It reads the defaults from a config file. So like, badabim badabum, even the user can't just chmod 777 /etc/passwd.

I think the same can be done for mount events and stuff. A daemon actively listening to mount events, and when one occurs, checks the options, if it is bad, it remounts it. It can also bind mount stuff there is no mount point there already.

Now you might think, hey, that sounds like a really dumb idea. Why would we need to complicate stuff by having a binary daemon to do these stuff when we can just do like shell scripts and stuff. That is a point, but there are more points to consider. First of all, it is faster (big time) and safer and also the code does not look more complicated than a shell script. Our current way is rather non conventional. A package should not edit apt overrides and stuff for example. Also it is non optimal too. A daemon would make sure everything is hardened all the time, and not the user, not any program, not apt or anything else, no one can interfere with the hardened file permissions (including hiding hardware) and mount points. (unmounting will result in a remount)

So thats just like an idea of mine. I think it would be really cool. If you are like open to at least considering the option I will finish the draft to completion as I said. But yeah, if we don't do that, I think we would better just avoid the binding to itself stuff. It is a complicated process and it requires a sophisticated solution (even with fstab).

[adrelanos]

I don't want a daemon that keep reverting things because then that daemon might fight with malware for a race condition. Keeping reverting permissions isn't the same as a clean permission denial.

All of that effort for an unclean band-aid on top would be better spent by fixing these things upstream in a clean way.

[monsieuremre]

I don't want a daemon that keep reverting things because then that daemon might fight with malware for a race condition. Keeping reverting permissions isn't the same as a clean permission denial.

Ok I see. You can't just trigger the daemon to falsely do this tho. This assumes the malware has root privileges.

Of course upstream fixing is the ideal but it ain't happening any time soon. Maybe have this secure mount check and file permissions check work on boot with a hook? It is basically what we already do. The thing we had and then deleted, the dracut hook script, I think it was not the wrong approach. I think the problems with it can be fixed maybe.

I don't know, I'm just thinking.

[monsieuremre]

We can add the bind mounts as kernel parameters, it turns out. Systemd first parses fstab. Let's say there is a /home line there, bc there is a partition. It generates a mount unit for home from fstab. Then it parses the kernel params, these are like extra lines in the fstab. Let's say we put bind home to home with bla bla. It silently and quietly gives a warning, saying that a unit for home is already generated and there is a duplicate entry in fstab for home in fstab, so skipping. So it skips our bind mount if there is a line in fstab. If there is none, it binds. Is this solution desirable for you?

Otherwise I'm still in support of the remount service, written in c or something preferably. The solution above won't be useful until the next debian release anyhow.

[adrelanos]

monsieuremre:

We can add the bind mounts as kernel parameters, it turns out. Systemd first parses fstab. Let's say there is a /home line there, bc there is a partition. It generates a mount unit for home from fstab. Then it parses the kernel params, these are like extra lines in the fstab. Let's say we put bind home to home with bla bla. It silently and quietly gives a warning, saying that a unit for home is already generated and there is a duplicate entry in fstab for home in fstab, so skipping. So it skips our bind mount if there is a line in fstab. If there is none, it binds. Is this solution desirable for you?

Interesting.

Could you update the wiki please?

• add this new method

• update /etc/fstab method with issues

[monsieuremre]

Literally we get as a result what you want. We just get a warning if you look at the logs. Duplicate entry in fstab, so skipping the second one. Which is what we actually want, so no problem. So I don't see why we don't just do this. Then, the user can do anything and everything during installation and everything will be securely mounted still.

Of course we can't use this because debian being debian and stuff. Systemd is too old on stable. I know it is really difficult to change bases. Changing to another debian derivative as the base would be significantly easier at least. Maybe those options should be exhausted first before considering other bases. Even using ubuntu would be really really helpful and better, if there werent any issues.

[adrelanos]

So I don't see why we don't just do this.

Reasons for my Could you update the wiki please? question: clean, methodical, organized, high quality work, maintainability, ability for third-party review (being able to follow thought process and reach similar conclusion or find flaws).

[monsieuremre]

Closing in favor of the new pull. In case it gets rejected, will reopen this one.