On 6/6/2017 7:51 AM, Igor Stoppa wrote: > On 06/06/17 17:36, Tetsuo Handa wrote: >> Igor Stoppa wrote: >>> For the case at hand, would it work if there was a non-API call that you >>> could use until the API is properly expanded? >> Kernel command line switching (i.e. this patch) is fine for my use cases. >> >> SELinux folks might want >> >> -static int security_debug; >> +static int security_debug = IS_ENABLED(CONFIG_SECURITY_SELINUX_DISABLE); > ok, thanks, I will add this > >> so that those who are using SELINUX=disabled in /etc/selinux/config won't >> get oops upon boot by default. If "unlock the pool" were available, >> SELINUX=enforcing users would be happy. Maybe two modes for rw/ro transition helps. >> >> oneway rw -> ro transition mode: can't be made rw again by calling "unlock the pool" API >> twoway rw <-> ro transition mode: can be made rw again by calling "unlock the pool" API > This was in the first cut of the API, but I was told that it would > require further rework, to make it ok for upstream, so we agreed to do > first the lockdown/destroy only part and the the rewrite. > > Is there really a valid use case for unloading SE Linux? It's used today in the Redhat distros. There is talk of removing it. You can only unload SELinux before policy is loaded, which is sort of saying that you have your system misconfigured but can't figure out how to fix it. You might be able to convince Paul Moore to accelerate the removal of this feature for this worthy cause. > Or any other security module. I suppose that you could argue that if a security module had been in place for 2 years on a system and had never once denied anyone access it should be removed. That's a reasonable use case description, but I doubt you'd encounter it in the real world. Another possibility is a security module that is used during container setup and once the system goes into full operation is no longer needed. Personally, I don't see either of these cases as compelling. "systemctl restart xyzzyd". -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
