From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754463AbdDRGGp (ORCPT ); Tue, 18 Apr 2017 02:06:45 -0400 Received: from mail-qk0-f171.google.com ([209.85.220.171]:35742 "EHLO mail-qk0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750917AbdDRGGl (ORCPT ); Tue, 18 Apr 2017 02:06:41 -0400 MIME-Version: 1.0 In-Reply-To: <13615.1491830208@warthog.procyon.org.uk> References: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk> <149142340198.5101.8171352010918423590.stgit@warthog.procyon.org.uk> <31421.1491569449@warthog.procyon.org.uk> <13615.1491830208@warthog.procyon.org.uk> From: Andy Shevchenko Date: Tue, 18 Apr 2017 09:06:40 +0300 Message-ID: Subject: Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down To: David Howells Cc: "linux-kernel@vger.kernel.org" , matthew.garrett@nebula.com, linux-efi@vger.kernel.org, One Thousand Gnomes , Greg Kroah-Hartman , acpi4asus-user , Platform Driver , linux-security-module , keyrings@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 10, 2017 at 4:16 PM, David Howells wrote: > Andy Shevchenko wrote: > >> >> It looks a bit fragile when responsility of whatever reasons kernel >> >> can't serve become a driver burden. >> >> Can we fix this in debugfs framework instead? >> > >> > Fix it with debugfs how? We can't offload the decision to userspace. >> >> I mean to do at least similar like you have done for module >> parameters. So, instead of putting above code to each attribute in >> question make a special (marked) attribute instead and debugfs >> framework will know how to deal with that. > > Hmmm... It's tricky in that debugfs doesn't have any of its own structures, > but is entirely built on standard VFS ones, so finding somewhere to store the > information is going to be awkward. I see. > One obvious solution is to entirely lock > down debugfs in secure boot more, but that might be a bit drastic. But this sounds sane! debugFS for debugging, not for production. If someone is using secure kernel it means pure production use (otherwise one may do temporary hacks in kernel). If one still needs debugfs in secure mode, it sounds to me as architectural bug in code in question. > > Note that it's still going to be a driver burden to some extent anyway. The > driver has to tell the core what needs to be restricted. > > Further, I guess configfs needs attention also. -- With Best Regards, Andy Shevchenko From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Shevchenko Subject: Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down Date: Tue, 18 Apr 2017 09:06:40 +0300 Message-ID: References: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk> <149142340198.5101.8171352010918423590.stgit@warthog.procyon.org.uk> <31421.1491569449@warthog.procyon.org.uk> <13615.1491830208@warthog.procyon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <13615.1491830208-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: David Howells Cc: "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org, linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, One Thousand Gnomes , Greg Kroah-Hartman , acpi4asus-user , Platform Driver , linux-security-module , keyrings-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-efi@vger.kernel.org On Mon, Apr 10, 2017 at 4:16 PM, David Howells wrote: > Andy Shevchenko wrote: > >> >> It looks a bit fragile when responsility of whatever reasons kernel >> >> can't serve become a driver burden. >> >> Can we fix this in debugfs framework instead? >> > >> > Fix it with debugfs how? We can't offload the decision to userspace. >> >> I mean to do at least similar like you have done for module >> parameters. So, instead of putting above code to each attribute in >> question make a special (marked) attribute instead and debugfs >> framework will know how to deal with that. > > Hmmm... It's tricky in that debugfs doesn't have any of its own structures, > but is entirely built on standard VFS ones, so finding somewhere to store the > information is going to be awkward. I see. > One obvious solution is to entirely lock > down debugfs in secure boot more, but that might be a bit drastic. But this sounds sane! debugFS for debugging, not for production. If someone is using secure kernel it means pure production use (otherwise one may do temporary hacks in kernel). If one still needs debugfs in secure mode, it sounds to me as architectural bug in code in question. > > Note that it's still going to be a driver burden to some extent anyway. The > driver has to tell the core what needs to be restricted. > > Further, I guess configfs needs attention also. -- With Best Regards, Andy Shevchenko From mboxrd@z Thu Jan 1 00:00:00 1970 From: andy.shevchenko@gmail.com (Andy Shevchenko) Date: Tue, 18 Apr 2017 09:06:40 +0300 Subject: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down In-Reply-To: <13615.1491830208@warthog.procyon.org.uk> References: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk> <149142340198.5101.8171352010918423590.stgit@warthog.procyon.org.uk> <31421.1491569449@warthog.procyon.org.uk> <13615.1491830208@warthog.procyon.org.uk> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Mon, Apr 10, 2017 at 4:16 PM, David Howells wrote: > Andy Shevchenko wrote: > >> >> It looks a bit fragile when responsility of whatever reasons kernel >> >> can't serve become a driver burden. >> >> Can we fix this in debugfs framework instead? >> > >> > Fix it with debugfs how? We can't offload the decision to userspace. >> >> I mean to do at least similar like you have done for module >> parameters. So, instead of putting above code to each attribute in >> question make a special (marked) attribute instead and debugfs >> framework will know how to deal with that. > > Hmmm... It's tricky in that debugfs doesn't have any of its own structures, > but is entirely built on standard VFS ones, so finding somewhere to store the > information is going to be awkward. I see. > One obvious solution is to entirely lock > down debugfs in secure boot more, but that might be a bit drastic. But this sounds sane! debugFS for debugging, not for production. If someone is using secure kernel it means pure production use (otherwise one may do temporary hacks in kernel). If one still needs debugfs in secure mode, it sounds to me as architectural bug in code in question. > > Note that it's still going to be a driver burden to some extent anyway. The > driver has to tell the core what needs to be restricted. > > Further, I guess configfs needs attention also. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html