Re: [PATCH 0/2] [RFC] sysfs: Add hook for checking the file capability of opener
From: Greg Kroah-Hartman
Date: Sun Dec 30 2018 - 09:45:53 EST
On Sun, Dec 30, 2018 at 09:28:54PM +0800, Lee, Chun-Yi wrote:
> There have some discussion in the following mail loop about checking
> capability in sysfs write handler:
A sysfs callback should not care about stuff like this.
Worst case, do a simple:
you don't care or need to worry about the file handle for that at all,
> Sometimes we check the capability in sysfs implementation by using
> capable function.
Which should be fine, right?
> But the checking can be bypassed by opening sysfs
> file within an unprivileged process then writing the file within a
> privileged process. The tricking way has been exposed by Andy Lutomirski
> for CVE-2013-1959.
And who does this for a sysfs file? And why?
> Because the sysfs_ops does not forward the file descriptor to the
> show/store callback, there doesn't have chance to check the capability
> of file's opener.
Which is by design. If you care about open, you are using sysfs wrong.
> This patch adds the hook to sysfs_ops that allows
> different implementation in object and attribute levels for checking
> file capable before accessing sysfs interfaces.
No, please no.
> The callback function of kobject sysfs_ops is the first implementation
> of new hook. It casts attribute to kobj_attribute then calls the file
> capability callback function of attribute level. The same logic can
> be implemented in other sysfs file types, like: device, driver and
> bus type.
> The capability checking logic in wake_lock/wake_unlock sysfs interface
> is the first example for kobject. It will check the opener's capability.
Why doesn't the file permission of that sysfs file determine who can or
can not write to that file?