Linux – Effect of nosuid on executables inside the mounted filesystem

linuxmountsetuid

Let it be known that I barely understand what setuid/setgid/whatever is. I think it has something to do with what user a program is executed as. This brings me to nosuid.

In Security Enhancements in Android 4.3, Google says

The /system partition is now mounted nosuid for zygote-spawned processes,
preventing Android applications from executing setuid programs.

It makes no sense to me to say that a filesystem in Linux is mounted "for" anything, as if the way it is mounted can be relative to a process or executable. If the system partition on Android devices is mounted with nosuid, then how can any of the system's core executables run as root, which they need to do in the earliest stages of startup?

Best Answer

Possibly relevant line earlier in the same document:

No setuid/setgid programs. Added support for filesystem capabilities to Android system files and removed all setuid/setguid programs. This reduces root attack surface and the likelihood of potential security vulnerabilities.

Regarding your final question:

If the system partition on Android devices is mounted with nosuid, then how can any of the system's core executables run as root, which they need to do in the earliest stages of startup?

nosuid doesn't prevent root from running processes. It is not the same as noexec. It just prevents the suid bit on executables from taking effect, which by definition means that a user cannot then run an application that would have permission to do things that the user doesn't have permission to do himself.

Also relevant here is an understanding of what "zygote" actually is; try reading https://android.stackexchange.com/a/77308

_{Disclaimer: I'm not an Android expert.}

Related Solutions

Does the noexec mount option imply nosuid

Thanks for the link LJKims, it helps me to answer my own question. I forgot that the suid/sgid bit can also be set for directories.

According to the GNU coreutils documentation files and directories that are created in a suid-directory inherit the owner of the directory (sgid-directories inherit the group obviously). So, if you want to avoid this behaviour, setting both noexec and nosuid on a mount point makes sense.

For completeness: in my tests on a current Debian, the suid bit on directories takes no effect, but only the sgid bit makes files/directories inherit the group of the directory.

# mkdir /test
# chmod 6777 /test
# ls -ld /test
drwsrwsrwx 2 root root 4096 Jun 10 18:50 /test
$ mkdir /test/foo; touch /test/bar
$ ls -l /test
-rw-r--r-- 1 user root    0 Jun 10 18:51 bar
drwxr-sr-x 2 user root 4096 Jun 10 18:51 foo

Edit: For completeness: The nosuid mount option does not affect sgid-directories (on Debian 8 at least).

# mount -o loop,nosuid test.img /test
# mkdir /test/foo
# chmod 2777 /test/foo
$ touch /test/foo/bar; mkdir /test/foo/baz
$ ls -l /test/foo
-rw-r--r-- 1 user root    0 Jun 12 09:46 bar
drwxr-sr-x 2 user root 4096 Jun 12 09:46 baz

Why does sudo fail inside docker complaining about nosuid

According to this GitHub post by asbe,

Containers on one host could sudo just fine, but on a nearly equivalent host the error occured. Finally figured out that the cause was because the problematic host used "overlay" as storage driver and the other "aufs". Both docker installations had moved /var/lib/docker to a drive mounted with "nosuid". Turns out "overlay" respects the "nosuid". Just making sure that /var/lib/docker was mounted on a disk with "nosuid" removed resolved all issues. (Curiously - this does not happen with the setup using "aufs")

(Emphasis added by me.)

Indeed, I was mounting /var/lib/docker from another drive with the nosuid option enabled. I disabled nosuid with this command:

sudo mount -n -o remount,suid /mount/for/var/lib/docker

Then sudo worked after restarting the container.

Best Answer

Related Solutions

Does the noexec mount option imply nosuid

Why does sudo fail inside docker complaining about nosuid

Related Question