Conversation

Replying to
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.
1
1
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
Replying to and
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
2
Replying to and
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
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
Show replies