[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xsm/flask: improve unknown permission handling
On 11/27/2014 10:33 AM, Andrew Cooper wrote: On 27/11/14 15:23, George Dunlap wrote:On Tue, Nov 25, 2014 at 6:05 PM, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:When an unknown domctl, sysctl, or other operation is encountered in the FLASK security server, use the allow_unknown bit in the security policy (set by running checkpolicy -U allow) to decide if the permission should be allowed or denied. This allows new operations to be tested without needing to immediately add security checks; however, it is not flexible enough to avoid adding the actual permission checks. An error message is printed to the hypervisor console when this fallback is encountered.Thanks -- I do think as Konrad said however, that when building with debug=y, we want the failure to be more obvious. A crash is probably the best thing. I guess we want something like the following after the printk in avc_unknown_permission()? #ifndef NDEBUG BUG(); #endifASSERT(!"Flask default policy error"); provides rather more information in the panic message, and avoids the #ifdefs. ~Andrew This allows any (privileged or unprivileged) guest to trigger the ASSERT and cause a hypervisor crash on a debug build. Given that XSA-37 was considered a security vulnerability due to this type of behavior, I am hesitant to deliberately add a path to trigger a hypervisor crash, even if it makes testing easier. -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |