Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
What is this restriction for in terms of safety? And when connecting external drives via USB, the root password is not required. I can't understand the logic.
I use the following rule in the fstab to connect the internal drive at runtime:
LABEL=disk /media/user/disk ext4 rw,nosuid,nodev,noexec,discard,relatime,user
How would such a rule add vulnerability?
Mounting filesystems has multiple very high security risks, and should not be taken lightly.
Having said that, there are multiple tools (like udisks and the user option in fstab) that run with elevated privileges and try to mitigate risks while allowing users to mount disks. Most of the mitigations work by carefully controlling mount options.
Here is a short (and incomplete) list of possible risks:
To summarize, mount is a system critical function and its effects can severely impact system integrity and security, so it should only be allowed by non-admin users in extremely restricted conditions.
/etc/fstab does not actually restrict mount options on Linux, just specifying both device and mount point when mounting causes options in /etc/fstab to be ignored by default with the version of mount provided by util-inux (and it also has options to ignore the options in /etc/fstab even if you just specify device or mount point).
Jan 10, 2022 at 13:43
fstab entries do not limit the possible mount options for filesystems, they do not only limit but explicitly specify the mount options that apply to unprivileged mounting enabled by the appearance of the user option in such an entry.
Jan 10, 2022 at 17:32
On most modern Linux distributions, there is a helper called udisks that allows users to mount removable drives, such as USB drives, so that they don't have to have root privileges. However, this helper doesn't typically run on non-removable disks, so it won't apply to internal drives.
The main reason that mounting a disk requires privileges is because it introduces the kernel to untrusted data, which is risky. The file system could be malicious or malformed, such as by having self-referential data structures, and this could lead an unprivileged user to cause a DoS or arbitrary code execution. Various other reasons are possible as well, as outlined by user10489.
More importantly, the same privileges are required for both mounting and unmounting, and generally the reason that udisks only works on removable drives is that allowing the user logged into a machine at the console to unmount an internal disk could cause the system to stop working. For example, if I had a restricted kiosk or business center computer and could unmount the root file system, I could take the kiosk out of service for everyone else until someone came to reboot it. This is the reason that unmounting drives typically requires privileges, since Unix systems are designed for multple users.
It's hard to tell why the system asks you for a password, without knowing the command you're running. fstab certanly can't ask you for a password, as it is not an executable file.
As you have user specified for /media/user/disk, running mount /media/user/disk as a regular should not ask for a password. In fact, mount never asks for a password at all, it either succeeds or fails. You're probably running sudo mount /media/user/disk, and sudo asks you for a password anyway, because it has no way of knowing the command you're about to run doesn't need to be executed as root
Also note that noexec, nosuid, and nodev parameters are implied when user is specified, so they have no effect.
What is this restriction for in terms of safety? And when connecting external drives via USB, the root password is not required. I can't understand the logic.
Unix-like systems were designed as multi-user systems and mounting of drives was/is considered an administrative action. A disk may contain data that some users are not allowed to access, it may contain setuid binaries that create a security risk.
As desktop (and even more so laptop) systems that are typically used by a single user at a time became more common, mechanisms were devised to grant the user who is logged into the computer locally some permissions that would normally be reserved to the system administrator. There have been several generations of such systems over the years, as far as I can tell Debian currently use policykit for this purpose.
Most Linux distributions with desktops default to granting users who are logged in locally permission to mount "removable" media. The logic is presumably that removable disks are under the control of the person sitting at the computer and they wouldn't be very useful if every time someone wanted to insert or eject a disk they had to call a sysadmin over. The security vulnerabilities of mounting are mitigated to some extent by restricting the mount location and mount options.
When USB drives came along, they got grouped with removable media from the perspective of the default policy, presumably because that is how in-practice most users use them.
If you are running a high-security shop you will probably want to review the default policies. Default policies in an OS distribution will always be a compromise between security and usability. Mounting a potentially malicious drive even with restricted mount options does bring some risks.
Internal drives on the other hand are still considered the domain of the system administrator and may contain stuff the user currently sitting at the computer is not supposed to access.
Originally, only root could do any mounting.
One reason for this is that arbitrary mounting allows you to mount something over /etc which contains a passwd (and shadow for systems which have it) with contents you control, so you can then log in as any user including root. This is why when user mounts were added they were restricted to specific, safe locations, either by specifying fixed posibilities in /etc/fstab or via tools which only mount in places reserved for them (e.g. pmount). In addition to the obvious problem with replacing /etc, in principle any directory might be security critical depending on what software is being used, so it's not sufficient to block access to a fixed list of dangerous places.
Another way to get root access if you can mount is to mount a filesystem which has a set-uid executable in it. This is why user mounts must always disable setuid for anything they mount. When a volume is mentioned in fstab setuid can be left enabled because the volume has been specifically permitted by the administrator so should be as safe as any other part of the filesystem.
And thirdly, if there is a volume which is normally mounted at a specific place (e.g. /home/alice/secretproject/bigdata) then it may contain data which is normally protected by the permission on a higher directory (in this case, presumably, /home/alice/secretproject). If you could mount it elsewhere, then you could gain access you shouldn't have (this could be mitigated by alice setting the permissions for all files in the root of the volume, but that is weak as it also requires remembering to do it when new files are added). When user mounts are permitted, this weakness is avoided in two different ways. For internal volumes, you can only mount them via fstab, so the administrator has deliberately made them available at fixed places. For external drives, the fact that you have physical posession of the device means you could put it in any machine you control, so by letting you mount it you are not being given any access you don't already have. This is why the default does not allow the same for internal drives. You might be accessing the system remotely with the volume inside the computer securely locked away in a room you don't have access to, so allowing you to mount the volume gives you access you wouldn't otherwise have.
I note that other answers mention malformed filesystem. This is clearly nonsense as external USB drives could just as easily be malformed and since they are under the control of the person inserting them could be used as an attack if malformed filesystems cause a problem. In contrast, an internal device could have been vetted by the administrator so potential malformation is not a reason to prohibit users mounting it.
mountrequires root, whereasudisksdoes notLABEL=diskdoes not work for the internal disk. Have you tried/dev/sdaX(or/dev/hdaX) instead ofLABEL=disk? I doubt that the difference is an intended behavior.