[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181230144835.GB18985@kroah.com>
Date: Sun, 30 Dec 2018 15:48:35 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: "Lee, Chun-Yi" <joeyli.kernel@...il.com>
Cc: "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>,
"Martin K . Petersen" <martin.petersen@...cle.com>,
Randy Dunlap <rdunlap@...radead.org>,
Joe Perches <joe@...ches.com>,
Bart Van Assche <bvanassche@....org>,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
"Lee, Chun-Yi" <jlee@...e.com>, Chen Yu <yu.c.chen@...el.com>,
Giovanni Gherdovich <ggherdovich@...e.cz>,
Jann Horn <jannh@...gle.com>, Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH 2/2] PM / Sleep: Check the file capability when writing
wake lock interface
On Sun, Dec 30, 2018 at 09:28:56PM +0800, Lee, Chun-Yi wrote:
> The wake lock/unlock sysfs interfaces check that the writer must has
> CAP_BLOCK_SUSPEND capability. But the checking logic can be bypassed
> by opening sysfs file within an unprivileged process and then writing
> the file within a privileged process. The tricking way has been exposed
> by Andy Lutomirski in CVE-2013-1959.
Don't you mean "open by privileged and then written by unprivileged?"
Or if not, exactly how is this a problem? You check the capabilities
when you do the write and if that is not allowed then, well
And you are checking the namespace of the person trying to do the write
when the write happens, which is correct here, right?
If you really want to mess with wake locks in a namespaced environment,
then put it in a real namespaced environment, which is {HUGE HINT} not
sysfs.
So no, this patch isn't ok...
thanks,
greg k-h
Powered by blists - more mailing lists