Re: [Xen-devel] [PATCH] xsm/flask: improve unknown permission handling

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 03/12/14 18:37, Daniel De Graaf wrote:
> 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.
>

XSA-37 was only an XSA because the rules at the time were unclear as
whether it was an issue or not.  At the same time, the rules were
clarified to state that issues in a debug build only are not security
issues.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel