Security purpose of asking admin password to mount partition on Linux

Question

So I divided my 250GB laptop drive into 2 partitions and some swap. On the second partition which is an ext4 60GB partition I installed Fedora 17. On the other bigger NTFS partition I've got Win XP and files I use when running both operating systems.

When I wanted to access the NTFS partition fedora asked me for my admin password to mount that partition. Why does it do that? What security purpose does it have?

Mounting the NTFS partition every time I boot would be cumbersome. I see a lot of guides on how to circumvent this but I'm not the kind of person who just goes around changing things without understanding them.

Perhaps a more straight question would be: If I do this how would that effect the security of my system? Should I do it, to avoid having to mount my NTFS partition every time I boot into Linux?

Answer 1

When I wanted to access the NTFS partition fedora asked me for my admin password to mount that partition. Why does it do that? What security purpose does it have?

As everybody else has said, you must be the root user to mount partitions, barring some special exceptions such as defining the partition and setting the user flag on the entry in /etc/fstab.

Why this is important to restrict is because mount can layer any mount point on top of any other directory, or even just one directory tree on top of another. With permission to run mount, I could put /home/jeff/bin on top of /bin using mount /home/jeff/bin /bin -o bind. Suddenly everybody is using the version of su, ls, or anything else I wish from my directory.

As doing the above would demonstrate, mount points don't need to be empty. Everything in a directory that is mounted on top of simply becomes unaccessible. Mount is capable of turning just about anything into a directory structure too, not just partitions. Loopback filesystems and remote network drives are also possible mount sources.

So, in multiuser system, one isn't able to walk all over the filesystem structure using mount because it would completely break security restrictions and any assumption that files are coming from the location you expect them to be because somebody could simply mount one directory to mask another.

Answer 2

Allowing anyone to mount any filesystem at any location would open a number of security holes.

• An obvious one is that the filesystem driver gets to access the underlying device. This may be hardware that the system administrator does not want to expose to users.
• Another obvious one is that there may be files that allow users to gain privileges. A setuid root shell, for example. Or a device node that allows raw access to the memory or disk or other hardware resource. Allowing a user to mount an arbitrary filesystem allows him to create arbitrary setuid/setgid programs and device nodes.
• A more subtle issue is that mounting a filesystem might create files in an unexpected location. Some applications read files in fixed locations, or trust files where the chain of directories from the root to the file is entirely owned by one user. Mounting a different filesystem along the path could allow the mounter to replace legitimate files by arbitrary content. For example, you could then mount a copy of /etc with a different passwd file with a root password set by you. Or you could mount a different directory on top of a user's home directory and provide your own .ssh/authorized_keys.
• Another concern is that filesystem drivers are often written for performance and reliability with well-formed filesystems. If a filesystem is malformed, it may trigger a bug in the driver that allows whoever controls the underlying device to execute code in the context of the filesystem driver, which traditionally runs in the kernel.

You can declare a device, mount point and mount options in /etc/fstab to mount a filesystem automatically at boot time. It's up to the system administrator not to put anything “dangerous” there, for example no mounting of unknown filesystems in system locations, disable setuid except on the root filesystem, etc.

The old-fashioned way of allowing ordinary users to mount transient filesystems is to put the user mount option on an fstab, typically combined with noauto. user automatically implies three other options: nosuid, nodev and noexec. These options disable setuid/setgid files (those bits have no effect), device files (device nodes have no effect), and executable files (the executable bit is ignored except on directories) respectively. The nosuid and nodev options are critical; noexec can be disabled (by adding exec after user) in almost all situations. Here's a typical fstab line for a removable device:

/dev/cdrom  /media/cdrom  iso9660  noauto,user,exec

A more modern method to allow users to mount removable devices is to install the pmount program. This program has more flexible policies than fstab, which only allows a predefined list. Pmount enforces several constraints, including requiring that the device be declared as removable and the mount point be an empty directory under /media.

For network resources, the traditional approach to go beyond a predefined list is an automounter. The automounter is typically configured to allow users to mount only network filesystems (NFS, Samba), only from vetted hosts (or at least only inside a domain), with predefined options including nodev and nosuid.

A more modern approach to allowing users to mount filesystems is to move the filesystem driver out of the kernel. FUSE is the de facto standard here (on Solaris, Linux, *BSD, OSX). The user must have access to the underlying device (if any) since all device accesses are performed by an unprivileged process. For the same reason, a bug in the filesystem driver will not compromise the security of the operating system. The user must own the mount point, so he will not be able to make files appear where he could otherwise not make files appear. Setuid and setgid bits are ignored. It is, however, possible to make files be owned by any user, no just the user doing the mounting.

Answer 3

fedora asked me for my admin password

As Zzz correctly says, only root can mount/unmount partitions. Actually, only root can do many things, for example including binding to ports below 1024.

With only one root user, sharing the root password becomes a problem - moreover, enabling direct login as root could be considered a security risk in much the same vein as one might rename the Administrator account on Windows - to deflect a common target.

Ubuntu solves this problem by generating a random password for root on install, and adding users that need root access to a specific group which is allowed to run commands via sudo in /etc/sudoers. Root login is then blocked, and running admin commands can be done from a normal user via sudo, gksudo or from the root prompt via sudo -i.

Fedora has gone half way there - root login is still allowed, but users that are in the wheel group can run sudo with their own password (rather than root). The specific line in /etc/sudoers that enables this is:

%wheel ALL=(ALL) ALL

Now, two historical notes:

• Some commands in Fedora aren't aware of the use of sudo and require root. Fedora root commands used to be run via su -c which still occurs in the docs in places - so sometimes you will need the root password.
• Historically, su stands for "switch user" and the wheel group is the group allowed to run su.

And some final notes on unix security:

• you'll have heard of setuid and setgid bits. These allow a process to be run in the context of the owning user and group respectively, rather than who started them, and is the traditional way of allowing users to start processes that need some root-level functionality.
• This is now actually deprecated - fedora has adopted posix capabilities in preference to this, which distribute root capabilities out as needed, allowing many processes to be started non-root.

Answer 4

[You have a Windows XP install, and you're worried about security? :p]

(Optional) The rights are currently elevated for anyone in the wheel group (system administrators). You can select only particular users e.g. this way

sounds good so far. I would want to check the permissions on the filesystem after it's mounted, which they don't mention explicitly. E.g. run "mount" and look for the "uid" mount option on this partition. I expect it's there alright though.

Then the implication is that any compromise of your Linux user can easily compromise the entire Windows install - and therefore the entire system, as soon as you boot into Windows. This isn't necessarily a big deal. Once your sudo/su-using user is compromised, you've already lost! Unless this is a multi-user system, once your user is compromised, that affects all the important stuff - passwords you enter on your keyboard, your files, emails, online activity, etc. And privilege escalation vulnerabilities crop up pretty frequently anyway.

If you wanted to work on defense in depth, you could reorganize the partitions so your shared data was on a different partition to Windows XP. This is recommended only if you are able to back up all your data, because there's lots of room to make mistakes when reorganizing partitions.

Alternatively you could try achieving the same effect with a custom init script. Mount the entire FS with your desired uid= option, bind mount your shared data directory to a second mount point, then unmount the original. I'm pretty sure it works for FAT anyway. I hope there's no sneaky way to bypass that - people do use "filesystem namespaces" as a security tool, and it's not known-bad, like chroot is.

Answer 5

Only root can mount partitions (unless configured otherwise). Otherwise anyone could do harm by unmounting partitions, changing mount options, etc.