Process namespaces and hidepid both place restrictions on processes seeing each other, as can security modules. Unsure if that's what they're referring to and don't feel like trying to find that in a video.
Conversation
Replying to
I'd understand that from normal users but root on Linux should show all pids (or have an option to show them).
Yeah, need more info on this to understand fully.
Watching video now but don't really want it scan back to find it either.
2
1
Replying to
Unconstrained root in the top-level namespace can see all the processes. There isn't necessarily any actual root on a system after early boot since root can restrict itself with MAC/MLS via security modules, or could set up namespaces and enter those without staying in top level.
2
2
I think init will always be in the top-level process namespace but there's no reason it can't spawn everything in namespaces below it. You can check if you're in the top-level namespace and then you know you probably aren't seeing everything.
2
1
2
This reminds me of someone I came across on FreeBSD, they ran with an init_script that would cpuset init down to half or so of the CPUs on the system so that everything else spawns with only half.
It'd be kind of neat to run everything under init in jails, but I guess that's a
2
Since Android has strict whole system SELinux MAC/MLS policies, there are only a few core processes (init, ueventd, vold) with something resembling actual root access in a production (user) build. Even init, etc. are still somewhat contained after init loads the SELinux policy.
1
1
It's still somewhat useful even for those processes since it's what provides some of the exploit mitigations like forbidding in-memory or storage dynamic native code execution, etc. Normal processes can only execute code from immutable, verified images (OS images or APEX images).
1
1
For example, if we decide to add a setting which needs to change the value of a sysctl, we need to add that sysctl as something init can write (or add a new one) and add a property for it to init scripts which is itself labelled and can only be written by the allowed domains.
1
1
One of the upstream things we did was getting Android to kernel.perf_event_paranoid=3 by default to forbid profiling by applications. Had to be wired up exactly like that where `adb shell` domain can write a property to enable profiling which the Android SDK does automatically.
1
1
It's not incredibly useful for init itself to be restricted but it does help to understand what it actually does and uses at runtime and avoids a lot of unexpected things happening. Can end up mitigating the impact of bugs even though it's not one of the real sandboxed domains.
1
2
1
I think even on Fuchsia which is entirely based around object capabilities and implements *nix APIs in libc as a compatibility layer, it would be useful to have statically defined security policies (note: SELinux on RHEL/Fedora doesn't remotely resemble how Android uses it).