> -----Original Message-----
> From: Alan Cox [mailto:[email protected]]
> Sent: Friday, October 13, 2017 10:20 AM
> To: Limonciello, Mario <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> 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
