[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();
#endif

ASSERT(!"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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.