ROOT USER AND SELINUX:
root (with UID 0) is the super user in Discretionary Access Control (DAC) implementation of *NIX operating systems. DAC is allowed by-default i.e. anyone can access anything unless UIDs, GIDs and permission mode restrict something. So
root can do anything because it's the kernel's SUPER USER who isn't denied anything.
SELinux is Mandatory Access Control (MAC) which is denied by-default i.e. no one can access anything unless a policy rule is defined to allow the access. So there is no SUPER CONTEXT which is allowed to do anything, whatever the UID is. You have to define a rule to allow any operation you want to perform on your device.
Please note that Access Controls (DAC or MAC) are enforced by kernel at back end, who is the actual operating system.
HOW SELINUX IS ENFORCED ON ANDROID?
SELinux policy rules are defined when building ROM and saved as a binary file
/sepolicy (or as
split-policy). This policy is loaded by
init (the very first process started in kernel's SELinux domain) before starting any services/daemons/processes on boot. Kernel starts with SELinux
permissive if built with option
SECURITY_SELINUX_DEVELOP=y (which is the default as discussed here and here). After loading policy,
init - when still running with kernel's context - sets SELinux
enforcing (depending on ROM build type and kernel parameter
androidboot.selinux (0)) and then switches to init's own context. From here afterwards, even
init isn't allowed by policy to revert back to
permissive mode (1, 2). Neither the policy can be modified even by
root user (3).
However there is one exception to above said rules. On
u:r:su:s0 - which is the context
adb shell gets when
adbd is run as root (4) or when
/system/xbin/su is executed (5) - is allowed to do anything, including setting SELinux permissive (6).
But on a final production (
user) build of ROM, the only way to
setenforce 0 or to modify policy is to take control of booting process before SELinux is set
init. That's what rooting solutions like Magisk do by replacing/patching
/sepolicy in RAM disk (
boot.img). Magisk runs root processes with context
u:r:magisk:s0 which is allowed by patched policy to do anything.
Once you have rights (granted by DAC and MAC) to play with SELinux policy, you can define new SELinux policy rules as explained here.
Coming to your question:
selinux is enforcing but I want it to be permissive which will never happen with stock kernel
No. SELinux is set
init, not by kernel, except if built with
SECURITY_SELINUX_ENFORCING=y option (7).
a higher context to do things like
supolicy --live to patch selinux policy
There is no higher context that is allowed to do anything. You can't set mode to
permissive and can't patch policy on
what is the (target) context that will allow any other (source) context to execute the script?
As said, there is no higher source context that can do anything to others. Likewise there is no lower target context that lets others do anything.
Also when executing a script, there isn't necessarily a single target context. Every file that the script uses (binaries, configurations, logs etc.) may have its different context label. And typetransitions can change source contexts too.
If you want to modify policy, you can get all
avc denials from kernel log and then define new SELinux rules accordingly:
~# dmesg -w | grep avc:
Since you are already on
eng build, only replace kernel binary (
zImage) in your
boot.img if you want to replace kernel. Otherwise you get stuck by using
boot.img of a
/init doesn't set SELinux
enforcing on boot (8)
/sepolicy allows root
adb shell to do anything including
load_policy as explained above
If your kernel is built with
SECURITY_SELINUX_ALWAYS_ENFORCE, you can't set SELinux
permissive once set