LinuxQuestions.org - cifs-utils-6.4, mount.cifs setuid root

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - cifs-utils-6.4, mount.cifs setuid root - is it safe? (https://www.linuxquestions.org/questions/linux-security-4/cifs-utils-6-4-mount-cifs-setuid-root-is-it-safe-4175572094/)

cifs-utils-6.4, mount.cifs setuid root - is it safe?

Hi,

Is it safe to have /sbin/mount.cifs setuid root as of cifs-utils version 6.4?

I've been looking a bit, but unfortunately cannot find anything authoritative.
Some claim it's not safe, some say the opposite. And all I've found is quite dated.

Thanks for the help!

--
Best regards,
Andrzej Telszewski

well, keep in mind that if you mount it to root, you are giving that full access to executable to the drive. i don't think that there is a high likelihood that something is going to go wrong/bad happening but a better idea might be to give the drive permissions equivalent to root privileges or something rather than mounting to the root uid or rather use umask to give it a masked permission.

you know, i guess what i am saying is probably not that big of a help, i think i would just avoid that...it just feels like it might be a bad idea. i dont see a good idea to do that plus there are easy ways to give the same permissions so i would avoid it. basically i guess it is unlikely but possible something might execute as a result of mounting by root uid.

i personally would not do it but it is your system so...

Hi,

Quote:

I'm sorry, but I don't understand exactly what you mean ;) Could you try to explain it in more details or different wording? By "mount it to root" you mean running mount setuid root? What do you mean by: "you are giving that full access to executable to the drive"? It's rather new topic for me, so I might not get exactly what you mean.

Quote:

you know, i guess what i am saying is probably not that big of a help, i think i would just avoid that...it just feels like it might be a bad idea.

That's the point. I'm looking for some authoritative answer. For example, sshd runs as root, and we are fine with that. Rather than feeling, I'd prefer scientific facts :)

Quote:

i dont see a good idea to do that plus there are easy ways to give the same permissions so i would avoid it.

I'm using mount.cifs with setuid root for exactly the reason of being easy for the user. I define the share in /etc/fstab and then the user can easily mount it. I'm not aware of other solution that would work flawlessly among different desktop environments. I'm using Xfce as DE, but Konqueror as file manager. Thanks to the share being defined in /etc/fstab, the user can mount the share by simply clicking on the icon that shows up on the desktop. I don't depend on gvfs nor kio slave and the share is easily accessible from everywhere, just because it's mounted on well defined mount point.

Quote:

basically i guess it is unlikely but possible something might execute as a result of mounting by root uid.

Can you provide more details? What do you mean?

Quote:

i personally would not do it but it is your system so...

I'm rather also security focused, as much as my knowledge allows ;) For that reason I'm seeking the very answer to my question ;)

Now, this is my /etc/fstab entry:

Code:

//OLAB/ola  /home/antezu/share/olab-ola  cifs  users,dir_mode=0700,file_mode=0600,noauto,rw,uid=antezu,gid=users,credentials=/home/antezu/.samba.olab.txt  0  0

Is there any security threat lurking somewhere?

Next thing: on my system /bin/mount is setuid root, but it does not allow regular users to do mounts, for example:

Code:

$ ls -l /bin/mount

-rwsr-xr-x 1 root root 37704 Dec 11 04:39 /bin/mount*

$ /bin/mount /home/antezu/downloads/ /home/antezu/playground/ -obind

mount: only root can use "--options" option

And now the same thing with mount.cifs if I remove the share definition from /etc/fstab and try to do the mount on the command line:

Code:

/bin/mount //OLAB/ola  /home/antezu/share/olab-ola -tcifs -ousers,dir_mode=0700,file_mode=0600,rw,uid=antezu,gid=users,credentials=/home/antezu/.samba.olab.txt

mount: only root can use "--options" option

$ /bin/mount //OLAB/ola  /home/antezu/share/olab-ola -tcifs 

mount: only root can use "--types" option

$ /bin/mount //OLAB/ola  /home/antezu/share/olab-ola

mount: only root can do that

$ ls -l /sbin/mount.cifs 

-rwsr-xr-x 1 root root 35464 Feb 11 21:29 /sbin/mount.cifs*

$ /sbin/mount.cifs //OLAB/ola  /home/antezu/share/olab-ola  -ousers,dir_mode=0700,file_mode=0600,rw,uid=antezu,gid=users,credentials=/home/antezu/.samba.olab.txt

mount.cifs: permission denied: no match for /home/antezu/share/olab-ola found in /etc/fstab

$ /sbin/mount.cifs //OLAB/ola  /home/antezu/share/olab-ola 

mount.cifs: permission denied: no match for /home/antezu/share/olab-ola found in /etc/fstab

I can't seem to find a way to mount the share by regular user if it's not defined in /etc/fstab. So the question remains, what is wrong with having mount.cifs setuid root? I understand that having bad entry in /etc/fstab can lead to security problems, but so would configuring sshd to allow password-less root logins ;) BTW, is my /etc/fstab entry for the share written in a safe manner?

Thanks for your help!

--
Best regards,
Andrzej Telszewski

What's wrong with defining it at /etc/fstab?

Hi,

Quote:

Originally Posted by MrTux (Post 5500326)

What's wrong with defining it at /etc/fstab?

If you understood me in that way, then I didn't mean that, I don't mean that there's something wrong with defining it at /etc/fstab.

The question is: is having mount.cifs setuid root as of cifs-utils version 6.4 considered to be a security risk? That is, can a regular user cause harm using it in some way?

As I demonstrated (up to my knowledge) in the previous post, regular user cannot do much with mount.cifs as long as the share is not defined in /etc/fstab. So, if the /etc/fstab share definition is correct, is there any security risk in allowing regular user to mount the share?

--
Best regards,
Andrzej Telszewski

Sometimes it is possible to run a program with a deliberately crafted command line which triggers a bug (eg a buffer overrun) and allows arbirary code to be run. If the program is being run as a user, then the arbirary code will also run as that user and have limited permissions. If the program is being run as root then this code will have root permissions and will not be restricted from causing harm to your system e.g. reading users files, altering the system files themselves, attacking other systems... When a program is setuid root it allows any user to run it with any command line arguments as if they had root permissions, which is why this should be avoided if possible.

I could not find any specific reported vulnerabilities for cifs-6.4, but I found that cifs-utils-6.4 fixed a bug which allowed a bogus user credentials to cause a stack overflow and potentially cause unspecified impact from unknown vectors http://cve.mitre.org/cgi-bin/cvename...=CVE-2014-2830. The possibility of other undiscovered bugs remain.

For mount.cifs to do its job mounting a share it needs to be run as root. However instead of making mount.cifs setuid root, you can instead set up sudo in such a way as to allow only specific users to run the program with specified command line arguments. This will make it harder for an attacker to supply a deliberately crafted command line or custom credentials to exploit vulnerabilities similar to the bug above. Details on setting this up can be found at https://wiki.gentoo.org/wiki/Mount

So if you run sudo visudo and add the following lines into /etc/sudoers

Code:

antezu: ALL=NOPASSWD: /bin/mount /home/antezu/share/olab-ola/, /bin/mount /home/antezu/share/olab-ola

antezu: ALL=NOPASSWD: /bin/umount /home/antezu/share/olab-ola/, /bin/umount /home/antezu/share/olab-ola

this will allow the user antezu (only) to mount and unmount the share using the following

Code:

$ sudo mount /home/antezu/share/olab-ola

$ sudo umount /home/antezu/share/olab-ola

This allows users to mount their shares arbirarily from the command line. However like you I am hoping to allow the user to click the icon in the file manager to mount or unmount the network share. I am using Dolphin and have not yet been able to make it work. I think I need to find the exact command line that the file manager is using to mount the share and put it into /etc/sudoers, or perhaps just ensure that the file manager uses sudo when it mounts.

Quote:

Originally Posted by MrTux (Post 5500326)

What's wrong with defining it at /etc/fstab?

Nothing, if you know ahead of time what you will be mounting. But that is not always posible.

For example: mounting user data folders from a AD service. We have the user's data folder automatically mounted via the PAM system using the user's password (while PAM knows it). We ended up SUID'ing (with other restrictions) the mount.cifs to root so the pam mount sub-program (which does all the AD lookups to work out the CIFS to be mounted) can do the mount. With any one of 2000 users, and no pre-knowledge of their password you can't really put it into the fstab.

It is also why sudo (which was considered) could not do the task, too many users. Now we could have the sub-program SUID to a special user, do its job (including vetting all arguments etc), then use a sudo call to mount.cifs.

From what I could see mount.cifs was actually made with SUID in mind. There were indications from its early usage, though nothing concrete. The only real way to check is to either look at the source code to see if it does privilege handling (sure indicator it can be SUID), or contact a developer. I have done neither so can't give a definitive answer.

Hi,

Let me rephrase my question:
Has mount.cifs as of cifs-utils-6.4 been given sufficient audit to assume it is secure to have mount.cifs setuid root?

We believe that using sudo is safe, because it most probably has been given much attention. It all boils down to the same point: if mount.cifs was considered as safe as sudo, then there was no difference between running mount.cifs through sudo or having mount.cifs setuid root. I guess :^)

--
Best regards,
Andrzej Telszewski

That is the question! And I wouldn't mind knowing the answer myself, as I have 'assumed' it was safe like many other people.