0

I have met a weird problem on a Samsung Galaxy Note 2, running Android 4.3, with an origin-forgetton rooted rom.

  1. getenforce returns "Permissive", so selinux is Permissive.
  2. cat /proc/self/status returns CapBnd/CapEff/CapPrm ffffffffffffffff after su, so all the capabilities are granted.
  3. su is from chainfire's SuperSU.

The syndrome is, after su any executable under /data calling execve() fails with EACCES. BUT, execve() under /data is permitted by a normal user.

To demonstrate, all the following experiments are carried out after su. Compile the following program into a static linked binary, say execve.

# gcc -static execve.c -o execve

/* execve.c */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int
main(int argc, char *argv[])
{
  char *newargv[] = { NULL, "hello", "world", NULL };
  char *newenviron[] = { NULL };

  if (argc != 2) {
    fprintf(stderr, "Usage: %s <file-to-exec>\n", argv[0]);
    exit(EXIT_FAILURE);
  }

  newargv[0] = argv[1];

  execve(argv[1], newargv, newenviron);
  perror("execve");   /* execve() only returns on error */
  exit(EXIT_FAILURE);
}

Running "execve /system/bin/ls" should be equivalent to "ls hello world".

But if execve is put under any subdirectory of /data, "execve /system/bin/ls" results in "Permission Denied".

  1. If execve is put into any of /, /system, /cache, /mnt/obb. execve() works.
  2. Remounting /data with exactly the same mount options as /cache does not help.
  3. Symlinking a subdirectory from /cache into /data containing execve works.

    ln -s /cache/test /data/test # /data/test/execve works

    And in reverse, execve does not work.

    ln -s /cache/test1 /data/test1 # /cache/test1/execve Permission Denied

  4. Bind mount /data to /bind. /bind/execve works, but /data/execve does not.

    mount -o bind /data /bind

Conclusion: There is soming preventing any executables under /data from making execve() syscall. The mechanism has nothing to do with the filesystem attributes, and symlink is dereferenced before the mechanism is applied.

Question: What mechanism in Android could give this strange behavior?

Reference:

  • Hi, sorry I didn't know this question was too specific to developers. Feel free to make it read-only or move it to stackoverflow. – heroxbd Dec 20 '14 at 11:00
0

Samsung has some restrictions hardcoded directly into the kernel. These things differ per device, per kernel/firmware, and are a real drag to work with, or around. Try a different firmware.

  • Thank you very much Jorrit. Great to have you here. I'll try to replace the offensive kernel. – heroxbd Dec 15 '14 at 12:14
  • Reflashing the phone with cyanogenmod works. Thanks! – heroxbd Dec 20 '14 at 10:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.