Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range
On 02/20/2018 08:26 PM, Kees Cook wrote: > On Tue, Feb 20, 2018 at 3:17 PM, Andrew Morton >wrote: >> On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Long wrote: >> >>> Even with clamped sysctl parameters, it is still not that straight >>> forward to figure out the exact range of those parameters. One may >>> try to write extreme parameter values to see if they get clamped. >>> To make it easier, a warning with the expected range will now be >>> printed in the kernel ring buffer when a clamped sysctl parameter >>> receives an out of range value. >> This assumes that do_proc_dointvec_minmax_conv() and >> do_proc_douintvec_minmax_conv() are only ever called by privileged >> userspace. Because we mustn't give unprivileged applications a way to >> spam the kernel logs. >> >> That's presumably true in the case of the caller you just added, but I >> don't see what we can do to guarantee this in the future, so perhaps we >> should add some permission check to the pr_warn()? > How about pr_warn_ratelimited() instead? > > -Kees > My current thinking is to issue at most one warning per sysctl parameter as additional warning of the same kind does not provide additional information. -Longman
Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range
On 02/20/2018 08:26 PM, Kees Cook wrote: > On Tue, Feb 20, 2018 at 3:17 PM, Andrew Morton > wrote: >> On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Long wrote: >> >>> Even with clamped sysctl parameters, it is still not that straight >>> forward to figure out the exact range of those parameters. One may >>> try to write extreme parameter values to see if they get clamped. >>> To make it easier, a warning with the expected range will now be >>> printed in the kernel ring buffer when a clamped sysctl parameter >>> receives an out of range value. >> This assumes that do_proc_dointvec_minmax_conv() and >> do_proc_douintvec_minmax_conv() are only ever called by privileged >> userspace. Because we mustn't give unprivileged applications a way to >> spam the kernel logs. >> >> That's presumably true in the case of the caller you just added, but I >> don't see what we can do to guarantee this in the future, so perhaps we >> should add some permission check to the pr_warn()? > How about pr_warn_ratelimited() instead? > > -Kees > My current thinking is to issue at most one warning per sysctl parameter as additional warning of the same kind does not provide additional information. -Longman
Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range
On 02/20/2018 06:17 PM, Andrew Morton wrote: > On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Longwrote: > >> Even with clamped sysctl parameters, it is still not that straight >> forward to figure out the exact range of those parameters. One may >> try to write extreme parameter values to see if they get clamped. >> To make it easier, a warning with the expected range will now be >> printed in the kernel ring buffer when a clamped sysctl parameter >> receives an out of range value. > This assumes that do_proc_dointvec_minmax_conv() and > do_proc_douintvec_minmax_conv() are only ever called by privileged > userspace. Because we mustn't give unprivileged applications a way to > spam the kernel logs. > > That's presumably true in the case of the caller you just added, but I > don't see what we can do to guarantee this in the future, so perhaps we > should add some permission check to the pr_warn()? > Good point. Beside adding security check, another alternative is to use some kind of warn_once() for each sysctl parameter. That will limit the amount of spamming that is possible. It will require adding a flag to the ctl_table to mark an entry as warned. I think that will be less tricky than adding permission check. I can also use the new flag to designate that a sysctl parameter need to be clamped to the range instead of failing when out of range. With that, I don't need to introduce new clamping APIs. I can use the existing ones. I will work on v2 patch with that change. Thanks, Longman
Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range
On 02/20/2018 06:17 PM, Andrew Morton wrote: > On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Long wrote: > >> Even with clamped sysctl parameters, it is still not that straight >> forward to figure out the exact range of those parameters. One may >> try to write extreme parameter values to see if they get clamped. >> To make it easier, a warning with the expected range will now be >> printed in the kernel ring buffer when a clamped sysctl parameter >> receives an out of range value. > This assumes that do_proc_dointvec_minmax_conv() and > do_proc_douintvec_minmax_conv() are only ever called by privileged > userspace. Because we mustn't give unprivileged applications a way to > spam the kernel logs. > > That's presumably true in the case of the caller you just added, but I > don't see what we can do to guarantee this in the future, so perhaps we > should add some permission check to the pr_warn()? > Good point. Beside adding security check, another alternative is to use some kind of warn_once() for each sysctl parameter. That will limit the amount of spamming that is possible. It will require adding a flag to the ctl_table to mark an entry as warned. I think that will be less tricky than adding permission check. I can also use the new flag to designate that a sysctl parameter need to be clamped to the range instead of failing when out of range. With that, I don't need to introduce new clamping APIs. I can use the existing ones. I will work on v2 patch with that change. Thanks, Longman
Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range
On Tue, Feb 20, 2018 at 3:17 PM, Andrew Mortonwrote: > On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Long wrote: > >> Even with clamped sysctl parameters, it is still not that straight >> forward to figure out the exact range of those parameters. One may >> try to write extreme parameter values to see if they get clamped. >> To make it easier, a warning with the expected range will now be >> printed in the kernel ring buffer when a clamped sysctl parameter >> receives an out of range value. > > This assumes that do_proc_dointvec_minmax_conv() and > do_proc_douintvec_minmax_conv() are only ever called by privileged > userspace. Because we mustn't give unprivileged applications a way to > spam the kernel logs. > > That's presumably true in the case of the caller you just added, but I > don't see what we can do to guarantee this in the future, so perhaps we > should add some permission check to the pr_warn()? How about pr_warn_ratelimited() instead? -Kees -- Kees Cook Pixel Security
Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range
On Tue, Feb 20, 2018 at 3:17 PM, Andrew Morton wrote: > On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Long wrote: > >> Even with clamped sysctl parameters, it is still not that straight >> forward to figure out the exact range of those parameters. One may >> try to write extreme parameter values to see if they get clamped. >> To make it easier, a warning with the expected range will now be >> printed in the kernel ring buffer when a clamped sysctl parameter >> receives an out of range value. > > This assumes that do_proc_dointvec_minmax_conv() and > do_proc_douintvec_minmax_conv() are only ever called by privileged > userspace. Because we mustn't give unprivileged applications a way to > spam the kernel logs. > > That's presumably true in the case of the caller you just added, but I > don't see what we can do to guarantee this in the future, so perhaps we > should add some permission check to the pr_warn()? How about pr_warn_ratelimited() instead? -Kees -- Kees Cook Pixel Security
Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range
On Tue, Feb 20, 2018 at 03:17:05PM -0800, Andrew Morton wrote: > On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Longwrote: > > > Even with clamped sysctl parameters, it is still not that straight > > forward to figure out the exact range of those parameters. One may > > try to write extreme parameter values to see if they get clamped. > > To make it easier, a warning with the expected range will now be > > printed in the kernel ring buffer when a clamped sysctl parameter > > receives an out of range value. > > This assumes that do_proc_dointvec_minmax_conv() and > do_proc_douintvec_minmax_conv() are only ever called by privileged > userspace. Because we mustn't give unprivileged applications a way to > spam the kernel logs. > > That's presumably true in the case of the caller you just added, but I > don't see what we can do to guarantee this in the future, so perhaps we > should add some permission check to the pr_warn()? Beyond what we do with sysctl_perm() on proc_sys_call_handler()? Luis
Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range
On Tue, Feb 20, 2018 at 03:17:05PM -0800, Andrew Morton wrote: > On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Long wrote: > > > Even with clamped sysctl parameters, it is still not that straight > > forward to figure out the exact range of those parameters. One may > > try to write extreme parameter values to see if they get clamped. > > To make it easier, a warning with the expected range will now be > > printed in the kernel ring buffer when a clamped sysctl parameter > > receives an out of range value. > > This assumes that do_proc_dointvec_minmax_conv() and > do_proc_douintvec_minmax_conv() are only ever called by privileged > userspace. Because we mustn't give unprivileged applications a way to > spam the kernel logs. > > That's presumably true in the case of the caller you just added, but I > don't see what we can do to guarantee this in the future, so perhaps we > should add some permission check to the pr_warn()? Beyond what we do with sysctl_perm() on proc_sys_call_handler()? Luis
Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range
On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Longwrote: > Even with clamped sysctl parameters, it is still not that straight > forward to figure out the exact range of those parameters. One may > try to write extreme parameter values to see if they get clamped. > To make it easier, a warning with the expected range will now be > printed in the kernel ring buffer when a clamped sysctl parameter > receives an out of range value. This assumes that do_proc_dointvec_minmax_conv() and do_proc_douintvec_minmax_conv() are only ever called by privileged userspace. Because we mustn't give unprivileged applications a way to spam the kernel logs. That's presumably true in the case of the caller you just added, but I don't see what we can do to guarantee this in the future, so perhaps we should add some permission check to the pr_warn()?
Re: [PATCH 2/3] sysctl: Warn when a clamped sysctl parameter is set out of range
On Mon, 19 Feb 2018 11:53:50 -0500 Waiman Long wrote: > Even with clamped sysctl parameters, it is still not that straight > forward to figure out the exact range of those parameters. One may > try to write extreme parameter values to see if they get clamped. > To make it easier, a warning with the expected range will now be > printed in the kernel ring buffer when a clamped sysctl parameter > receives an out of range value. This assumes that do_proc_dointvec_minmax_conv() and do_proc_douintvec_minmax_conv() are only ever called by privileged userspace. Because we mustn't give unprivileged applications a way to spam the kernel logs. That's presumably true in the case of the caller you just added, but I don't see what we can do to guarantee this in the future, so perhaps we should add some permission check to the pr_warn()?