Score:0

Partition Mounting Weakness for /run/snapd/ns/lxd.mnt nsfs file system type

mx flag

so after a vulnerability scan on an ubuntu 20.04 instance I'm working on, 2 vulnerabilities were found. One of them was a partition mounting weakness and the proof of this vulnerability was that /run/snapd/ns/lxd.mnt partition does not have 'nodev' option set. I have searched and searched but I can't seem to find a fix for this. Very little information about this partition. Only information I found is that it is a namespace mount point with a nsfs filesystem type which is not listed in /proc/filesystems . I've been unable to find any information on how to unmount or remount this partition with the edited option set 'nodev' in order to fix this vulnerability. Any help with respect to this will very much be appreciated.

ru flag
What vulnerability scanner? It sounds like for several of those they may be 'false positives' or 'extremely minor' things - I see these in Rapid 7's scanner but we can't nodev everything (snap partition mounts can't be altered by end users typically, or even sysadmins to some extent)
Andy85 avatar
mx flag
Yes, this is Rapid 7 vulnerability scanner.
ru flag
From my personal experience, the 'nodev' vulnerabiltiy risk is *low* and can be ignored in some cases. Unfortunately, *you cannot change the mount options for snaps' loop mounts* so this is a "Not an issue" mount risk (loop mounts are also locked and not able to be edited, at least LXD's in this case is as such). `nsfs` mounts are also called 'local mounts' and 'loop mounts' because they're mounted as loop devices with fixed images.
Andy85 avatar
mx flag
Interesting. Thanks for your take. Do you have links to documentation on this, that I can read about? So that I'm well informed and also have some documentation to back my suggestion when speaking with the security team in my organization about making this vulnerability an exception.
ru flag
I'd have to dig - but you also need to tell your security team "Not everything is a vulnerability that *needs* to be addressed". I have to pull up the Rapid7 documentation on the 'risk' first and get back to you
Andy85 avatar
mx flag
Okay. Thanks, appreciate your time. Will also really appreciate it if you could get me some documentation.
Andy85 avatar
mx flag
So I know I'm being a little hard headed with this but I added this line - "tmpfs /run/snapd/ns/lxd.mnt tmpfs defaults,nodev 0 0" to /etc/fstab, did a reboot and run the vulnerability scan again and the PMW vulnerability was gone. but, now the mount point is of type tmpfs. changed the line above in /etc/fstab to "tmpfs /run/snapd/ns/lxd.mnt nsfs defaults,nodev 0 0" but that didn't revert the mount point to its original type of nsfs. Does any of these things I'm doing help with regards to fixing the vulnerability, or does it break my system in anyway?
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.