[Security Discussion] t0kt0ckus:
Thank you for your answer.

I've looked at your attached source, the main difference with my own wrapper is that you fork the process, I've tried also, behavior is the same. But, after reading your comment, I've modified my setuid/execve code, to make it more verbose about the real/effective/saved UIDs (using getresuid()).

shell@falcon_umts:/ $ test_su
Initial UIDs
ruid: 2000
[B]euid: 0[/B]
suid: 0
Setting UIDs ...
New UIDs
[B]ruid: 0
[/B]euid: 0
suid: 0
root@falcon_umts:/ # ls /data/
[I]opendir failed, Permission denied[/I]
1|root@falcon_umts:/ #

It clearly appears that, POSIX speaking, all go fine until the "Permission denied" error:

the effective uid is already 0 (just after the "adb shell" command), which is expected and documented, as the content of my /default.prop prevents the shell to revert its effective uid to its real one, which would then be 2000 (shell)

after the setuid(0) call, the real uid is successfully set to 0, as expected, because the suid bit is set AND we were already privileged (if not privileged, setuid() should only change the effective uid, as for "man 2 setuid")

after execve(..), the whole prompt, "root@falcon_umts:/ #", again confirms the real uid is 0 (root)

Yes, I definitely need to dig into the SELinux/Android stuff (see bellow), and will try to find the Chainfire posts you propose.

Neither dmseg (which is accessible) nor logcat shows any related error or warning.

I haven't any /selinux/enforce file, but it clearly appears from information bellow that SELinux is activated and enforced:

shell@falcon_umts:/ $ getenforce
[B]Enforcing[/B]
root@falcon_umts:/ # setenforce 0
setenforce: Could not set enforcing status: Permission denied
shell@falcon_umts:/ $ cat seapp_contexts
isSystemServer=true domain=system
user=system domain=system_app type=system_data_file
user=bluetooth domain=bluetooth type=bluetooth_data_file
user=nfc domain=nfc type=nfc_data_file
user=radio domain=radio type=radio_data_file
user=_app domain=untrusted_app type=app_data_file levelFrom=none
user=_app seinfo=platform domain=platform_app type=platform_app_data_file
user=_app seinfo=shared domain=shared_app type=platform_app_data_file
user=_app seinfo=media domain=media_app type=platform_app_data_file
user=_app seinfo=release domain=release_app type=platform_app_data_file
user=_isolated domain=isolated_app
user=shell domain=shell type=shell_data_file
user=log domain=log_app type=system_data_file
user=sprint_extension domain=carrier_ext type=platform_app_data_file
user=smartcard domain=smartcard type=smartcard_data_file

I'm a noob at SELinux, and I may be wrong, but I think a rule policy could prevent a user, being it root, to achieve certain actions. I need to read stuff about this.

The initial boot image that I modify (just add my suid shell /sbin/test_su) is the 4.4.2 one from sbf, and I expand/repack it using standard un*x tools (gunzip,cpio,...) and abootimg. Anything wrong with that ?

I build the C files using:

$ echo $CC
<android-ndk>/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc --sysroot=<android-ndk>/platforms/android-19/arch-arm
$ $CC -o test_su test_su.c

Should I use particular flags for gcc, to make it produce SELinux aware object files ?

[EDIT: stupid question, answer is no]

Again, thanks for your help and ideas.