linux-kernel - RE: [PATCH v7 10/15] platform/x86: dell-smbios: add filtering capability for requests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dcf35817f6234dac99b51e9eea2c7c78@ausx13mpc124.AMER.DELL.COM>
Date:   Fri, 13 Oct 2017 15:44:18 +0000
From:   <Mario.Limonciello@...l.com>
To:     <gnomes@...rguk.ukuu.org.uk>
CC:     <greg@...ah.com>, <dvhart@...radead.org>,
        <andy.shevchenko@...il.com>, <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <luto@...nel.org>,
        <quasisec@...gle.com>, <pali.rohar@...il.com>, <rjw@...ysocki.net>,
        <mjg59@...gle.com>, <hch@....de>
Subject: RE: [PATCH v7 10/15] platform/x86: dell-smbios: add filtering
 capability for requests

> -----Original Message-----
> From: Alan Cox [mailto:gnomes@...rguk.ukuu.org.uk]
> Sent: Friday, October 13, 2017 10:20 AM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> Cc: greg@...ah.com; dvhart@...radead.org; andy.shevchenko@...il.com;
> linux-kernel@...r.kernel.org; platform-driver-x86@...r.kernel.org;
> luto@...nel.org; quasisec@...gle.com; pali.rohar@...il.com;
> rjw@...ysocki.net; mjg59@...gle.com; hch@....de
> Subject: Re: [PATCH v7 10/15] platform/x86: dell-smbios: add filtering capability
> for requests
> 
> On Fri, 13 Oct 2017 15:03:10 +0000
> > Take off your "kernel" hat and put on a "customer" hat for a few moments
> > while I try to put this in practical terms why the whitelist approach doesn't
> > scale for what I'm trying to do.
> 
> As a customer I'm more worried about someone trashing my system or
> breaking my security.
> 
> > So considering the above isn't offering stuff like this a decision better made by
> the OEM?
> > If the OEM  doen't want customers to be able to modify something we don't
> offer it in the
> > manageability interface.  If the kernel community doesn't want people to be
> > modifying something the OEM does offer, it can just as well be blacklisted in
> the
> > kernel driver like the current filtering approach offers.
> 
> So you implement the rule
> 
> 	if (whitelisted & (capabilities && whitelist->capability_need) ==
> 	whitelist->capability_need))
> 		return ALLOWED;
> 
> 	if (capable(CAP_SYS_RAWIO))
> 		return ALLOWED;
> 
> 	return NO
> 
> This puts you in the position where - known tools work and can sometimes
> be unprivileged. Privileged tools with enough priv to screw the machien
> can work anyway. Which is better than the starting point
> 
> 
> You could further enhance this by having a CAP_SYS_RAWIO interface to add
> whitelist entries, or to add an eBPF filter that can also make decisions
> for you.
> 
> Now you've got the ability to push a policy update.
> 
> Alan

Thanks for this idea, I think it's productive in working towards a solution.

I'll give it some more thought on what items I feel should be whitelisted to
unprivileged processes.  I feel like the number of entries that match this will
be fairly low.

I think I'd actually like to meld this with your other ideas and what I've 
currently got.  What do you think of this approach:

	/* kernel community doesn't feel userspace should have access at all
	  * or other kernel drivers use this
	  */
	if (blacklisted)
		return NO;

	/* unprivileged access allowed */
 	if (whitelisted & (capabilities && whitelist->capability_need) ==
 	whitelist->capability_need))
 		return ALLOWED;
 
	/* not yet in whitelist, or need privs to do */
 	if (capable(CAP_SYS_RAWIO))
 		return ALLOWED;
 
 	return NO