[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] sysctl: XSM hook should not cause XEN_SYSCTL_getdomaininfolist to (appear to) fail
- To: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Tue, 2 May 2023 13:00:00 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=njO6siTvEdw9eAhZlRafJ1EmMyH9PhIGPS5uu3T0qFA=; b=TOjV+M3hwYwdyTS1NeD6RxzMpaPh7J3oiwl95PE/QHF28XUJAFBDclZ0FxnrFgeIHYil2PCQTm586RsUNpfrzy6MG1GRF+pIXWbvpfpv0YSZFdm2XjjZ7wwRaSc2VBM8peUEBMN6epqX9X6ZX9XPgazr1SoZTsuODXowGmqAWPZO9InA24VYWQuKddA9MLKIaGkYTn7ci/Clmxn3PTVuag0RNP7FjEwNheRmRwHYI99zt70ndHnZVM4/dbobv0cUAbeZ+DRyX0yDTn6ktSgBPkGllblf5LzUlAplII+pOmwrMZCBR+0Rfy9UOSGi3Jc49VfWa6zBmA6Rozojmo2Krw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mVUnNBhYuQztLClAKCXvWb0EkZ02/GwYzCpwEzH0pv0jvtve2nFvzqG0jV+3SdW3PCVqPZ4O/LhAbErA/TPpmL3+DyjVKNzNv+idOIEcaSFigg0MiF/GDlFKK1oAc/DoztiLgTxOku4aU65QXeKUPxj36pGor5K1I9P+oYGGmwUaniiJdXfP6jo14cStLIbyXzdcgu9yLax5IUWJ0C3oAm+M/qoduGeESu0QQfCucmJsVbxEyB15ohs6YctuMzxLZqREfm6MceDn6dR1ChuJb11cIhN8dzJYZFb7QxnifmSnHpdzHO48CJHQeRMHy3ZBt/vX9v+mKjI0yZHJbIWOJw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Tue, 02 May 2023 11:00:18 +0000
- Ironport-data: A9a23:7mCyP60ms8IletlK5fbD5T9wkn2cJEfYwER7XKvMYLTBsI5bp2QHy zZLDTjUMq6KNzCmfIx/aoi19hsO75Hcy4c1QQs6pC1hF35El5HIVI+TRqvS04F+DeWYFR46s J9OAjXkBJppJpMJjk71atANlVEliefTAOK6ULWeUsxIbVcMYD87jh5+kPIOjIdtgNyoayuAo tq3qMDEULOf82cc3lk8tuTS+XuDgNyo4GlD5gFmP6gR1LPjvyJ94Kw3dPnZw0TQGuG4LsbiL 87fwbew+H/u/htFIrtJRZ6iLyXm6paLVeS/oiI+t5qK23CulQRrukoPD9IOaF8/ttm8t4sZJ OOhF3CHYVxB0qXkwIzxWvTDes10FfUuFLTveRBTvSEPpqFvnrSFL/hGVSkL0YMkFulfG2FPr 8UEKgI3axmu3bvszK+Hdsl+v5F2RCXrFNt3VnBI6xj8VKxja7aTBqLA6JlfwSs6gd1IEbDGf c0FZDFzbRPGJRpSJlMQD5F4l+Ct7pX9W2QA9BTJ+uxqvi6Kk1QZPLvFabI5fvSQQspYhACAr 3/u9GXlGBAKcteYzFJp91r13rGfzX+kB9x6+LuQy9xhonuh/mgvDyY0UEe8jMCc1EGvYocKQ 6AT0m90xUQoz2SnVsL4XgG4iHecswQARsFLFOkn9ACKzLGS6AGcbkAGRDNcbN0ttOctWCcnk FSOmrvBFTFp9bGYV3+Z3rOVti+pfzgYK3cYYi0JRhdD5MPsyKkxkxbOQ9BLAKOzyNrvFlnY2 CuWpSIzg7ESi88j1Kih+13DxTW2qfDhUQod9gjRGGW/4WtEiJWNYoWp7R3R66ZGJYPAFF2Z5 iFbw46Z8fwECoyLmGqVWuIREbq15vGDdjrBnVpoGJpn/DOok5K+Qb1tDPhFDB8BGq45lfXBO Sc/ZSs5CEdvAUaX
- Ironport-hdrordr: A9a23:cV404KDrnjN+4c3lHelo55DYdb4zR+YMi2TDt3oddfU1SL38qy nKpp4mPHDP5wr5NEtPpTniAtjjfZq/z/5ICOAqVN/PYOCPggCVxepZnOjfKlPbehEX9oRmpN 1dm6oVMqyMMbCt5/yKnDVRELwbsaa6GLjDv5a785/0JzsaE52J6W1Ce2GmO3wzfiZqL7wjGq GR48JWzgDQAkj+PqyAdx84t/GonayzqK7b
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Tue, May 02, 2023 at 06:43:33AM -0400, Daniel P. Smith wrote:
>
>
> On 5/2/23 03:17, Jan Beulich wrote:
> > Unlike for XEN_DOMCTL_getdomaininfo, where the XSM check is intended to
> > cause the operation to fail, in the loop here it ought to merely
> > determine whether information for the domain at hand may be reported
> > back. Therefore if on the last iteration the hook results in denial,
> > this should not affect the sub-op's return value.
> >
> > Fixes: d046f361dc93 ("Xen Security Modules: XSM")
> > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> > ---
> > The hook being able to deny access to data for certain domains means
> > that no caller can assume to have a system-wide picture when holding the
> > results.
> >
> > Wouldn't it make sense to permit the function to merely "count" domains?
> > While racy in general (including in its present, "normal" mode of
> > operation), within a tool stack this could be used as long as creation
> > of new domains is suppressed between obtaining the count and then using
> > it.
> >
> > In XEN_DOMCTL_getpageframeinfo2 said commit had introduced a 2nd such
> > issue, but luckily that sub-op and xsm_getpageframeinfo() are long gone.
> >
>
> I understand there is a larger issue at play here but neutering the security
> control/XSM check is not the answer. This literally changes the way a FLASK
> policy that people currently have would be enforced, as well as contrary to
> how they understand the access control that it provides. Even though the
> code path does not fall under XSM maintainer, I would NACK this patch. IMHO,
> it is better to find a solution that does not abuse, misuse, or invalidate
> the purpose of the XSM calls.
>
> On a side note, I am a little concern that only one person thought to
> include the XSM maintainer, or any of the XSM reviewers, onto a patch and
> the discussion around a patch that clearly relates to XSM for us to gauge
> the consequences of the patch. I am not assuming intentions here, only
> wanting to raise the concern.
>
> So for what it is worth, NACK.
I assume the NACK is to the remarks after the '---'?
The patch itself doesn't change the enforcement of the XSM checks,
just prevents returning an error when the information from the last
domain in the loop can not be fetched.
Am I missing something?
Roger.
|
