This is incorrect. The process address space is created by fork(), the execve overwrites the application data only, not the environment (glibc atsecure removes some environment variables that affect the linker) but there is a significant chunk of data that is non-tranquil. Imagine doing a domain transition on a perl script, how many environment variables can affect the execution of the perl script that won’t be cleansed across the execve().

True. I probably should have corrected this. It should read: Yes evil but necessary in the Linux environment since the environment (et al) is relabeled during the transition. One way around this would be to do a full copy of the memory space on exec but I doubt the kernel maintainers would be interested. I’ll leave the old content in take but add a note to this effect.

The primary revocation issue is memory, shared memory and mmap()’d files are not able to be revoked when a new policy is loaded.

Yup shoulda went with this example anyways…. thats the more interesting case.

Notice both the subject tranquility and mmap/shm issues that crop are due to the memory susbsystem. Someone correct me if I’m wrong but SELinux could have maintained subject tranquility if the entire task struct was copied instead of overwritten on execve. All the data could have been copied to the new task struct, but the new task struct would contain the new sid. Given the lightweight nature of Linux process fork/execs I don’t it is worth the tradeoff.

Still, it is a relabel by definition thus violating the laws of tranquility but at the same time, I would argue, presents no revocation issues and doesn’t introduce the complexity of time into analysis. We trust the kernel to not begin execution of the program until the security context is correct. Without being a kernel expert, I would assume other processes on the system can’t interact with this process until the kernel actually runs it, and intuition tells us that a non-running application can’t really initiate any type of communication. Thus, during analysis we assume that the process and all it’s “metadata” has that label for it’s entire lifetime. Still a relabel is a relabel, one second the policy means one thing about a segment of memory, and the next it says another.

As for the mmap/shm issue I’ll actually update the entry to avoid scaring people about file relabels…

If dynamic transitions are evil shouldn’t all domain transitions be evil since they destroy tranquility?
No because normal domain transitions maintain tranquility. As stated above, the transitions happen on the execve call and the type is kept for the lifetime of the application. This means there is the complexity of time is never introduced. When one process starts another process one of three things can occur:

This is incorrect. The process address space is created by fork(), the execve overwrites the application data only, not the environment (glibc atsecure removes some environment variables that affect the linker) but there is a significant chunk of data that is non-tranquil. Imagine doing a domain transition on a perl script, how many environment variables can affect the execution of the perl script that won’t be cleansed across the execve().

So what about files? Can we just relabel files since revocation is fairly instantaneous?
No! Bad! First of all buffered reads and buffered writes could still complete (policy says one thing, the system is enforcing something else). Second of all time is an issue, how the heck can you analyze policy when one moment the policy means one thing and the next moment it means something else.

Also erroneous. By definition when revocation occurs the policy says one thing at one moment and another thing at another moment. The only affect here is a possible delay between when the old policy is enforcing and when the new policy takes affect.

Granted there are revocation issues but you aren’t covering any of them here. The primary revocation issue is memory, shared memory and mmap()’d files are not able to be revoked when a new policy is loaded.